diff --git a/404.html b/404.html index 72229f7a..6578ed4e 100644 --- a/404.html +++ b/404.html @@ -6,13 +6,13 @@ Page Not Found | Syscoin Docs - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/assets/images/diagram_SyscoinOverallDesign-77198a540dbcdd3a521218954402e779.png b/assets/images/diagram_SyscoinOverallDesign-77198a540dbcdd3a521218954402e779.png new file mode 100644 index 00000000..23c9f796 Binary files /dev/null and b/assets/images/diagram_SyscoinOverallDesign-77198a540dbcdd3a521218954402e779.png differ diff --git a/assets/images/diagram_SyscoinOverallDesign-82b321ac10a146b018bf18b1be2434ab.png b/assets/images/diagram_SyscoinOverallDesign-82b321ac10a146b018bf18b1be2434ab.png deleted file mode 100644 index 100907b6..00000000 Binary files a/assets/images/diagram_SyscoinOverallDesign-82b321ac10a146b018bf18b1be2434ab.png and /dev/null differ diff --git a/assets/js/7637bbfc.19c3b7d0.js b/assets/js/7637bbfc.6f23bdb0.js similarity index 99% rename from assets/js/7637bbfc.19c3b7d0.js rename to assets/js/7637bbfc.6f23bdb0.js index b64cf64f..93fdc38c 100644 --- a/assets/js/7637bbfc.19c3b7d0.js +++ b/assets/js/7637bbfc.6f23bdb0.js @@ -1 +1 @@ -"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[7283],{98338:(e,t,a)=>{a.d(t,{Zo:()=>h,kt:()=>y});var n=a(76687);function i(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function o(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function r(e){for(var t=1;t=0||(i[a]=e[a]);return i}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var l=n.createContext({}),c=function(e){var t=n.useContext(l),a=t;return e&&(a="function"==typeof e?e(t):r(r({},t),e)),a},h=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},p="mdxType",d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},u=n.forwardRef((function(e,t){var a=e.components,i=e.mdxType,o=e.originalType,l=e.parentName,h=s(e,["components","mdxType","originalType","parentName"]),p=c(a),u=i,y=p["".concat(l,".").concat(u)]||p[u]||d[u]||o;return a?n.createElement(y,r(r({ref:t},h),{},{components:a})):n.createElement(y,r({ref:t},h))}));function y(e,t){var a=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var o=a.length,r=new Array(o);r[0]=u;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[p]="string"==typeof e?e:i,r[1]=s;for(var c=2;c{a.r(t),a.d(t,{default:()=>h,frontMatter:()=>o,metadata:()=>r,toc:()=>s});var n=a(87250),i=(a(76687),a(98338));const o={sidebar_position:2},r={unversionedId:"intro/syscoin-what",id:"intro/syscoin-what",isDocsHomePage:!1,title:"A More Detailed Overview",description:"What is Syscoin?",source:"@site/docs/intro/syscoin-what.mdx",sourceDirName:"intro",slug:"/intro/syscoin-what",permalink:"/docs/intro/syscoin-what",version:"current",sidebarPosition:2,frontMatter:{sidebar_position:2},sidebar:"tutorialSidebar",previous:{title:"Syscoin in a Nutshell",permalink:"/docs/intro/nutshell"},next:{title:"Bitcoin Technology",permalink:"/docs/tech/bitcoin-tech"}},s=[{value:"What is Syscoin?",id:"what-is-syscoin",children:[]},{value:"What Syscoin Provides",id:"what-syscoin-provides",children:[]},{value:"Why Choose Syscoin?",id:"why-choose-syscoin",children:[]}],l={toc:s},c="wrapper";function h(e){let{components:t,...o}=e;return(0,i.kt)(c,(0,n.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"what-is-syscoin"},"What is Syscoin?"),(0,i.kt)("p",null,"Syscoin is a Bitcoin L2 that is ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/merged-mining"},"merge-mined")," with Bitcoin, and a modular Proof-of-Work blockchain solution that brings rollups to Bitcoin's PoW. Syscoin provides to Bitcoin a scalable data availability layer which is necessary for rollups (and other EVM or AltVM layers) to tap into Bitcoin's network in a safe and scalable way. Syscoin's base is comprised of a dual-chain Layer 1: the core is the Syscoin native (UTXO) blockchain providing ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/poda"},"data availability")," and ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/finality"},"finality"),". Running in tandem with the UTXO chain is an Ethereum Virtual Machine (EVM) chain called ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/nevm"},(0,i.kt)("em",{parentName:"a"},"NEVM"))," (Network-Enhanced Virtual Machine), which is merged mined alongside the UTXO chain and also inherits finality."),(0,i.kt)("p",null,"Originally brought to mainnet in 2014, the Syscoin protocol has been improved iteratively, settling into the robust and useful protocol that it is today. "),(0,i.kt)("p",null,"What percentage of Bitcoin's hashrate is supporting Syscoin? Compare to see:",(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("a",{parentName:"p",href:"https://www.coinwarz.com/mining/bitcoin/hashrate-chart"},(0,i.kt)("strong",{parentName:"a"},"Bitcoin hashrate")),(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("a",{parentName:"p",href:"https://www.coinwarz.com/mining/syscoin/hashrate-chart"},(0,i.kt)("strong",{parentName:"a"},"Syscoin hashrate"))),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"img",src:a(16400).Z})),(0,i.kt)("h2",{id:"what-syscoin-provides"},"What Syscoin Provides"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/poda"},(0,i.kt)("strong",{parentName:"a"},"PoDA"))," - Proof of Data Availability is an L1 DA protocol for rollups. It is hash-based and built on UTXO. Efficient, general purpose, easy to integrate."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://rollux.com"},(0,i.kt)("strong",{parentName:"a"},"Rollux"))," - An OPStack rollup anchored to Bitcoin through Syscoin's DA protocol. Provides 2-second blocktime, extremely low fees, and supports application layers on top. "),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/nevm"},(0,i.kt)("strong",{parentName:"a"},"NEVM"))," - Network-Enhanced Virtual Machine is the L1 EVM of Syscoin, made specifically for supporting rollups and other scaling layers."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Ordinals support")," - Our native Bitcoin-based UTXO chain remains closely up-to-date with Bitcoin Core and includes support for Taproot/Schnorr. This means there is a great deal of potential here for cross-chain and even cross-architecture (UTXO <-> EVM Rollup) ordinals. Further, our PoDA protocol means ordinal creators can secure data payloads in a new, more efficient way."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/sentrynodes"},(0,i.kt)("strong",{parentName:"a"},"Sentry Nodes and Finality"))," - Incentivized full nodes deterministically provide ",(0,i.kt)("a",{parentName:"li",href:"/docs/tech/finality"},"finality")," through multi-quorum chainlocks (4 x 400) as additive security on top of Bitcoin's PoW. Owners of these collateralized nodes receive rewards, including seniority benefits, for the services they provide to the network."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/z-dag"},(0,i.kt)("strong",{parentName:"a"},"Z-DAG"))," - Based upon Satoshi's \"snack machine\" concept, Z-DAG is a UTXO-based instant settlement protocol with probabilistic security used to enable a very high throughput of UTXO transfers. Works with UTXO-based assets. In a nutshell, it utilizes Bitcoin's mempool design as a DAG by providing double-spend awareness across a mesh topology."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/notary"},(0,i.kt)("strong",{parentName:"a"},"Notary rulesets"))," - This allows ",(0,i.kt)("a",{parentName:"li",href:"/docs/tech/tokens"},(0,i.kt)("em",{parentName:"a"},"Syscoin Platform Token (SPT)"))," creators to apply their own rulesets on transfers of their SPT and then accept or deny the transfers by signing or not signing the transactions. These off-chain rulesets enable SPT asset managers to maintain compliance even when regulations or business rules change.")),(0,i.kt)("h2",{id:"why-choose-syscoin"},"Why Choose Syscoin?"),(0,i.kt)("p",null,"Security: Syscoin provides manifold security as a settlement and data availability layer for rollups and other scaling solutions. First, leveraging merge-mining with Bitcoin, Syscoin is currently powered by around 60% of Bitcoin's own hashrate. This taps you into the world's best Proof-of-Work network for proven antifragility and fault tolerance as well as resilience against economic black swans, at a level which pure Proof-of-stake systems simply cannot match. Additionally, Syscoin's Sentry nodes provide multi-quorum chainlocks for an additive layer of finality which keeps intact the benefits of Proof-of-work while greatly mitigating the risks of 51% attacks and selfish mining. Furthermore, the security of Syscoin's data availability will soon extend to nearly any blockchain ecosystem through zkDA, a new Syscoin innovation in-progress that also brings a new level of cross-chain interoperability. All of this underscores Syscoin's commitment to robust security."),(0,i.kt)("p",null,"Scalability: With a unique and holistically modular design, Syscoin stands out with exceptional support for scalability layers. Providing a live dedicated data availability protocol on Layer 1 means Syscoin is already ideal for natively supporting rollups of all kinds as scaling layers. Rollux, the first rollup built on Syscoin, is a perfect example. Scalability, in this context, extends beyond transaction volume and speed of settlement; it also encompasses the affordability of transactions. Low cost execution makes Syscoin an attractive option for projects seeking a settlement layer for their rollup, especially those aiming to make frequent state commitments. In comparison to other EVM-based chains, Syscoin is more scalable and cost-effective, but that's not all."),(0,i.kt)("p",null,"Decentralization: The network boasts approximately 2,700 independently owned and operated Sentry nodes which work together deterministically to serve a decentralized finality mechanism. The rewards associated with hosting a Sentry node contribute to their growth and retention, including seniority benefits. Over 75% of these nodes have been active and collateralized for over two and half years. Furthermore, SYS, the native currency of Syscoin, has been in circulation since 2014 and is broadly distributed."),(0,i.kt)("p",null,"In summary, Syscoin is"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"modular"),(0,i.kt)("li",{parentName:"ul"},"exceptionally secure"),(0,i.kt)("li",{parentName:"ul"},"scalable"),(0,i.kt)("li",{parentName:"ul"},"decentralized"),(0,i.kt)("li",{parentName:"ul"},"flexible"),(0,i.kt)("li",{parentName:"ul"},"economical"),(0,i.kt)("li",{parentName:"ul"},"reliable")),(0,i.kt)("p",null,"Projects that are considering Syscoin, or that have questions, can reach out to the community and teams."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Contact us here: ",(0,i.kt)("a",{parentName:"li",href:"https://syscoin.org/contact"},"https://syscoin.org/contact")),(0,i.kt)("li",{parentName:"ul"},"Or you can connect with us on the Syscoin Discord server: ",(0,i.kt)("a",{parentName:"li",href:"https://discord.gg/syscoin"},"https://discord.gg/syscoin"))))}h.isMDXComponent=!0},16400:(e,t,a)=>{a.d(t,{Z:()=>n});const n=a.p+"assets/images/diagram_SyscoinOverallDesign-82b321ac10a146b018bf18b1be2434ab.png"}}]); \ No newline at end of file +"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[7283],{98338:(e,t,a)=>{a.d(t,{Zo:()=>h,kt:()=>y});var n=a(76687);function i(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function o(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function r(e){for(var t=1;t=0||(i[a]=e[a]);return i}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var l=n.createContext({}),c=function(e){var t=n.useContext(l),a=t;return e&&(a="function"==typeof e?e(t):r(r({},t),e)),a},h=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},p="mdxType",d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},u=n.forwardRef((function(e,t){var a=e.components,i=e.mdxType,o=e.originalType,l=e.parentName,h=s(e,["components","mdxType","originalType","parentName"]),p=c(a),u=i,y=p["".concat(l,".").concat(u)]||p[u]||d[u]||o;return a?n.createElement(y,r(r({ref:t},h),{},{components:a})):n.createElement(y,r({ref:t},h))}));function y(e,t){var a=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var o=a.length,r=new Array(o);r[0]=u;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[p]="string"==typeof e?e:i,r[1]=s;for(var c=2;c{a.r(t),a.d(t,{default:()=>h,frontMatter:()=>o,metadata:()=>r,toc:()=>s});var n=a(87250),i=(a(76687),a(98338));const o={sidebar_position:2},r={unversionedId:"intro/syscoin-what",id:"intro/syscoin-what",isDocsHomePage:!1,title:"A More Detailed Overview",description:"What is Syscoin?",source:"@site/docs/intro/syscoin-what.mdx",sourceDirName:"intro",slug:"/intro/syscoin-what",permalink:"/docs/intro/syscoin-what",version:"current",sidebarPosition:2,frontMatter:{sidebar_position:2},sidebar:"tutorialSidebar",previous:{title:"Syscoin in a Nutshell",permalink:"/docs/intro/nutshell"},next:{title:"Bitcoin Technology",permalink:"/docs/tech/bitcoin-tech"}},s=[{value:"What is Syscoin?",id:"what-is-syscoin",children:[]},{value:"What Syscoin Provides",id:"what-syscoin-provides",children:[]},{value:"Why Choose Syscoin?",id:"why-choose-syscoin",children:[]}],l={toc:s},c="wrapper";function h(e){let{components:t,...o}=e;return(0,i.kt)(c,(0,n.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"what-is-syscoin"},"What is Syscoin?"),(0,i.kt)("p",null,"Syscoin is a Bitcoin L2 that is ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/merged-mining"},"merge-mined")," with Bitcoin, and a modular Proof-of-Work blockchain solution that brings rollups to Bitcoin's PoW. Syscoin provides to Bitcoin a scalable data availability layer which is necessary for rollups (and other EVM or AltVM layers) to tap into Bitcoin's network in a safe and scalable way. Syscoin's base is comprised of a dual-chain Layer 1: the core is the Syscoin native (UTXO) blockchain providing ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/poda"},"data availability")," and ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/finality"},"finality"),". Running in tandem with the UTXO chain is an Ethereum Virtual Machine (EVM) chain called ",(0,i.kt)("a",{parentName:"p",href:"/docs/tech/nevm"},(0,i.kt)("em",{parentName:"a"},"NEVM"))," (Network-Enhanced Virtual Machine), which is merged mined alongside the UTXO chain and also inherits finality."),(0,i.kt)("p",null,"Originally brought to mainnet in 2014, the Syscoin protocol has been improved iteratively, settling into the robust and useful protocol that it is today. "),(0,i.kt)("p",null,"What percentage of Bitcoin's hashrate is supporting Syscoin? Compare to see:",(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("a",{parentName:"p",href:"https://www.coinwarz.com/mining/bitcoin/hashrate-chart"},(0,i.kt)("strong",{parentName:"a"},"Bitcoin hashrate")),(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("a",{parentName:"p",href:"https://www.coinwarz.com/mining/syscoin/hashrate-chart"},(0,i.kt)("strong",{parentName:"a"},"Syscoin hashrate"))),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"img",src:a(16400).Z})),(0,i.kt)("h2",{id:"what-syscoin-provides"},"What Syscoin Provides"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/poda"},(0,i.kt)("strong",{parentName:"a"},"PoDA"))," - Proof of Data Availability is an L1 DA protocol for rollups. It is hash-based and built on UTXO. Efficient, general purpose, easy to integrate."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"https://rollux.com"},(0,i.kt)("strong",{parentName:"a"},"Rollux"))," - An OPStack rollup anchored to Bitcoin through Syscoin's DA protocol. Provides 2-second blocktime, extremely low fees, and supports application layers on top. "),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/nevm"},(0,i.kt)("strong",{parentName:"a"},"NEVM"))," - Network-Enhanced Virtual Machine is the L1 EVM of Syscoin, made specifically for supporting rollups and other scaling layers."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Ordinals support")," - Our native Bitcoin-based UTXO chain remains closely up-to-date with Bitcoin Core and includes support for Taproot/Schnorr. This means there is a great deal of potential here for cross-chain and even cross-architecture (UTXO <-> EVM Rollup) ordinals. Further, our PoDA protocol means ordinal creators can secure data payloads in a new, more efficient way."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/sentrynodes"},(0,i.kt)("strong",{parentName:"a"},"Sentry Nodes and Finality"))," - Incentivized full nodes deterministically provide ",(0,i.kt)("a",{parentName:"li",href:"/docs/tech/finality"},"finality")," through multi-quorum chainlocks (4 x 400) as additive security on top of Bitcoin's PoW. Owners of these collateralized nodes receive rewards, including seniority benefits, for the services they provide to the network."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/z-dag"},(0,i.kt)("strong",{parentName:"a"},"Z-DAG"))," - Based upon Satoshi's \"snack machine\" concept, Z-DAG is a UTXO-based instant settlement protocol with probabilistic security used to enable a very high throughput of UTXO transfers. Works with UTXO-based assets. In a nutshell, it utilizes Bitcoin's mempool design as a DAG by providing double-spend awareness across a mesh topology."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/tech/notary"},(0,i.kt)("strong",{parentName:"a"},"Notary rulesets"))," - This allows ",(0,i.kt)("a",{parentName:"li",href:"/docs/tech/tokens"},(0,i.kt)("em",{parentName:"a"},"Syscoin Platform Token (SPT)"))," creators to apply their own rulesets on transfers of their SPT and then accept or deny the transfers by signing or not signing the transactions. These off-chain rulesets enable SPT asset managers to maintain compliance even when regulations or business rules change.")),(0,i.kt)("h2",{id:"why-choose-syscoin"},"Why Choose Syscoin?"),(0,i.kt)("p",null,"Security: Syscoin provides manifold security as a settlement and data availability layer for rollups and other scaling solutions. First, leveraging merge-mining with Bitcoin, Syscoin is currently powered by around 60% of Bitcoin's own hashrate. This taps you into the world's best Proof-of-Work network for proven antifragility and fault tolerance as well as resilience against economic black swans, at a level which pure Proof-of-stake systems simply cannot match. Additionally, Syscoin's Sentry nodes provide multi-quorum chainlocks for an additive layer of finality which keeps intact the benefits of Proof-of-work while greatly mitigating the risks of 51% attacks and selfish mining. Furthermore, the security of Syscoin's data availability will soon extend to nearly any blockchain ecosystem through zkDA, a new Syscoin innovation in-progress that also brings a new level of cross-chain interoperability. All of this underscores Syscoin's commitment to robust security."),(0,i.kt)("p",null,"Scalability: With a unique and holistically modular design, Syscoin stands out with exceptional support for scalability layers. Providing a live dedicated data availability protocol on Layer 1 means Syscoin is already ideal for natively supporting rollups of all kinds as scaling layers. Rollux, the first rollup built on Syscoin, is a perfect example. Scalability, in this context, extends beyond transaction volume and speed of settlement; it also encompasses the affordability of transactions. Low cost execution makes Syscoin an attractive option for projects seeking a settlement layer for their rollup, especially those aiming to make frequent state commitments. In comparison to other EVM-based chains, Syscoin is more scalable and cost-effective, but that's not all."),(0,i.kt)("p",null,"Decentralization: The network boasts approximately 2,700 independently owned and operated Sentry nodes which work together deterministically to serve a decentralized finality mechanism. The rewards associated with hosting a Sentry node contribute to their growth and retention, including seniority benefits. Over 75% of these nodes have been active and collateralized for over two and half years. Furthermore, SYS, the native currency of Syscoin, has been in circulation since 2014 and is broadly distributed."),(0,i.kt)("p",null,"In summary, Syscoin is"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"modular"),(0,i.kt)("li",{parentName:"ul"},"exceptionally secure"),(0,i.kt)("li",{parentName:"ul"},"scalable"),(0,i.kt)("li",{parentName:"ul"},"decentralized"),(0,i.kt)("li",{parentName:"ul"},"flexible"),(0,i.kt)("li",{parentName:"ul"},"economical"),(0,i.kt)("li",{parentName:"ul"},"reliable")),(0,i.kt)("p",null,"Projects that are considering Syscoin, or that have questions, can reach out to the community and teams."),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Contact us here: ",(0,i.kt)("a",{parentName:"li",href:"https://syscoin.org/contact"},"https://syscoin.org/contact")),(0,i.kt)("li",{parentName:"ul"},"Or you can connect with us on the Syscoin Discord server: ",(0,i.kt)("a",{parentName:"li",href:"https://discord.gg/syscoin"},"https://discord.gg/syscoin"))))}h.isMDXComponent=!0},16400:(e,t,a)=>{a.d(t,{Z:()=>n});const n=a.p+"assets/images/diagram_SyscoinOverallDesign-77198a540dbcdd3a521218954402e779.png"}}]); \ No newline at end of file diff --git a/assets/js/e0833ef8.03933a25.js b/assets/js/e0833ef8.03933a25.js deleted file mode 100644 index 1de30249..00000000 --- a/assets/js/e0833ef8.03933a25.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[540],{98338:(e,t,a)=>{a.d(t,{Zo:()=>d,kt:()=>u});var n=a(76687);function i(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function o(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function r(e){for(var t=1;t=0||(i[a]=e[a]);return i}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var l=n.createContext({}),c=function(e){var t=n.useContext(l),a=t;return e&&(a="function"==typeof e?e(t):r(r({},t),e)),a},d=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},h="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var a=e.components,i=e.mdxType,o=e.originalType,l=e.parentName,d=s(e,["components","mdxType","originalType","parentName"]),h=c(a),p=i,u=h["".concat(l,".").concat(p)]||h[p]||m[p]||o;return a?n.createElement(u,r(r({ref:t},d),{},{components:a})):n.createElement(u,r({ref:t},d))}));function u(e,t){var a=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var o=a.length,r=new Array(o);r[0]=p;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[h]="string"==typeof e?e:i,r[1]=s;for(var c=2;c{a.r(t),a.d(t,{default:()=>d,frontMatter:()=>o,metadata:()=>r,toc:()=>s});var n=a(87250),i=(a(76687),a(98338));const o={},r={unversionedId:"tech/poda",id:"tech/poda",isDocsHomePage:!1,title:"BitcoinDA (Data Availability on Layer 1)",description:"Overview",source:"@site/docs/tech/poda.mdx",sourceDirName:"tech",slug:"/tech/poda",permalink:"/docs/tech/poda",version:"current",frontMatter:{},sidebar:"tutorialSidebar",previous:{title:"Notary and Business Rulesets",permalink:"/docs/tech/notary"},next:{title:"Rollux",permalink:"/docs/tech/rollux"}},s=[{value:"Overview",id:"overview",children:[]},{value:"Sample BitcoinDA transaction",id:"sample-bitcoinda-transaction",children:[]},{value:"How to interact with BitcoinDA",id:"how-to-interact-with-bitcoinda",children:[{value:"syscoincreatenevmblob",id:"syscoincreatenevmblob",children:[]},{value:"syscoincreaterawnevmblob",id:"syscoincreaterawnevmblob",children:[]},{value:"listnevmblobdata",id:"listnevmblobdata",children:[]},{value:"getnevmblobdata",id:"getnevmblobdata",children:[]}]},{value:"How to run a BitcoinDA archive service",id:"how-to-run-a-bitcoinda-archive-service",children:[]}],l={toc:s},c="wrapper";function d(e){let{components:t,...o}=e;return(0,i.kt)(c,(0,n.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"overview"},"Overview"),(0,i.kt)("p",null,"Data availability is required to exist within the security domain of Layer 1 in order for rollups to properly serve critical financial applications by securing users\u2019 ability to exit to L1. Syscoin\u2019s L1 DA solution is called PoDA (Proof of Data Availability). Syscoin\u2019s PoDA differs from Ethereum\u2019s danksharding in how data is stored, presented, pruned, and how fees are calculated. PoDA has characteristics that make it a valuable alternative to Ethereum\u2019s work-in-progress data availability solution, Proto-Danksharding."),(0,i.kt)("p",null,"BitcoinDA\u2019s advantages can be summarized as:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Cheaper transactions"),(0,i.kt)("li",{parentName:"ul"},"No data sharding required"),(0,i.kt)("li",{parentName:"ul"},"Greater data throughput with efficient Keccak data blobs"),(0,i.kt)("li",{parentName:"ul"},"Secured by Bitcoin\u2019s own PoW plus Syscoin's finality"),(0,i.kt)("li",{parentName:"ul"},"More resilient to network-based outages/censorship"),(0,i.kt)("li",{parentName:"ul"},"Simpler data fee market based on Syscoin\u2019s UTXO fee market"),(0,i.kt)("li",{parentName:"ul"},"Nakamoto Assumption: Only one honest node is needed to guarantee data")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"BitcoinDA's design is based on PoDA (proof of data availability), which is a separation of concerns between data availability and data archiving with the protocol's purpose being the former.")),(0,i.kt)("div",{className:"admonition admonition-info alert alert--info"},(0,i.kt)("div",{parentName:"div",className:"admonition-heading"},(0,i.kt)("h5",{parentName:"div"},(0,i.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,i.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"14",height:"16",viewBox:"0 0 14 16"},(0,i.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M7 2.3c3.14 0 5.7 2.56 5.7 5.7s-2.56 5.7-5.7 5.7A5.71 5.71 0 0 1 1.3 8c0-3.14 2.56-5.7 5.7-5.7zM7 1C3.14 1 0 4.14 0 8s3.14 7 7 7 7-3.14 7-7-3.14-7-7-7zm1 3H6v5h2V4zm0 6H6v2h2v-2z"}))),"info")),(0,i.kt)("div",{parentName:"div",className:"admonition-content"},(0,i.kt)("p",{parentName:"div"},(0,i.kt)("strong",{parentName:"p"},"Purpose of BitcoinDA")," "),(0,i.kt)("ul",{parentName:"div"},(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Deterministically ensure and prove that data has been placed within the commons and that the public was given a sufficient and defined opportunity to archive it.")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Provide an on-chain hash necessary to verify the integrity of any archived data at a later time, and the option of custom hashes for other purposes a user might implement on top."))))),(0,i.kt)("p",null,"With BitcoinDA, by default, a Keccak256 hash of the full data blob is stored on Layer 1, while an assumption is made that at least one honest party in the world will archive the blob within at least a six-hour window of time - similar to the honesty assumption made when syncing a Bitcoin node (at least one honest node). After this window of time, the blob is pruned from the network's cache while its hash remains on-chain."),(0,i.kt)("p",null,"Validium (fully offchain DA) is also available as an alternative to BitcoinDA for less-critical applications where the focus might be on even lower cost and higher throughput by trading-off Layer 1 data security. However, in the case of Syscoin PoDA, Layer 1 data security is quite affordable; archivers store full data off-chain while you gain the security of an on-chain hash."),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"img",src:a(6023).Z})),(0,i.kt)("h2",{id:"sample-bitcoinda-transaction"},"Sample BitcoinDA transaction"),(0,i.kt)("p",null,"This transaction was submitted by Rollux L2 to the Syscoin Native (UTXO) Mainnet.",(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://blockbook.syscoin.org/tx/8de8bf84a1c55a06ad2d10ee10e036e51d122d02ded0a57ebddfd1da640aebc6"},"https://blockbook.syscoin.org/tx/8de8bf84a1c55a06ad2d10ee10e036e51d122d02ded0a57ebddfd1da640aebc6"))," "),(0,i.kt)("p",null,"Note: The version hash is visible in the raw transaction data as scriptPubKey.asm: \u201cOP_RETURN 20",(0,i.kt)("strong",{parentName:"p"},"e76700ef2ceab4e1f71af30a1fcf0662eedbb932aa66285ac30dbca46256e7d4"),"\u201d"),(0,i.kt)("p",null,"The hash of the data blob is stored on-chain as seen above in boldened portion of the sample's OP_RETURN. This should be used to prove the integrity of archived data at any future time."),(0,i.kt)("h2",{id:"how-to-interact-with-bitcoinda"},"How to interact with BitcoinDA"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Syscoin Core (>=v4.4) provides an RPC interface that enables use of the BitcoinDA protocol")),(0,i.kt)("p",null,"Once submitted, the transaction with version hash is stored onchain in the next available block, while the full data blob is made publicly available within the native chain\u2019s cache for a period of six hours of finality before being pruned. As long as the blob is cached, archiving services can access and store it. In the event that sufficient finality is absent, BitcoinDA will retain blobs in the cache until aforementioned finality threshold is met. This helps ensure published data is given proper guarantees to solve fisherman's dilemma even during adverse network conditions. "),(0,i.kt)("h3",{id:"syscoincreatenevmblob"},(0,i.kt)("inlineCode",{parentName:"h3"},"syscoincreatenevmblob")),(0,i.kt)("p",null,"Submit data blob with auto-generated Keccak256 versionHash (recommended)"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'syscoincreatenevmblob "data" ( overwrite_existing conf_target "estimate_mode" fee_rate )\n\nArguments:\n1. data (string, required) blob in hex\n2. overwrite_existing (boolean, optional, default=true) true to overwrite an existing blob if it exists, false to return versionhash of data on duplicate.\n3. conf_target (numeric, optional, default=wallet -txconfirmtarget) Confirmation target in blocks\n4. estimate_mode (string, optional, default="unset") The fee estimate mode, must be one of (case insensitive):\n "unset"\n "economical"\n "conservative"\n5. fee_rate (numeric or string, optional, default=not set, fall back to wallet fee estimation) Specify a fee rate in sat/vB.\n\nExamples:\n> syscoin-cli syscoincreatenevmblob "data"\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "syscoincreatenevmblob", "params": ["data"]}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,i.kt)("div",{parentName:"div",className:"admonition-heading"},(0,i.kt)("h5",{parentName:"div"},(0,i.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,i.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,i.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,i.kt)("div",{parentName:"div",className:"admonition-content"},(0,i.kt)("p",{parentName:"div"},"You can extend the TTL (time-to-live) of a BitcoinDA blob for another six hours by resubmitting the same exact blob with the ",(0,i.kt)("inlineCode",{parentName:"p"},"overwrite_existing")," flag set to TRUE."))),(0,i.kt)("h3",{id:"syscoincreaterawnevmblob"},(0,i.kt)("inlineCode",{parentName:"h3"},"syscoincreaterawnevmblob")),(0,i.kt)("p",null,"Submit data blob with custom (user-specified) versionHash. This might be useful if you wish to use a different hash algorithm or implement some custom commitment scheme as a layer on top of BitcoinDA. Otherwise, it is best to stick with the ",(0,i.kt)("inlineCode",{parentName:"p"},"syscoincreatenevmblob")," standard."),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'syscoincreaterawnevmblob "versionhash" "data" ( conf_target "estimate_mode" fee_rate )\n\nArguments:\n1. versionhash (string, required) Version hash of the blob\n2. data (string, required) data in hex\n3. conf_target (numeric, optional, default=wallet -txconfirmtarget) Confirmation target in blocks\n4. estimate_mode (string, optional, default="unset") The fee estimate mode, must be one of (case insensitive):\n "unset"\n "economical"\n "conservative"\n5. fee_rate (numeric or string, optional, default=not set, fall back to wallet fee estimation) Specify a fee rate in sat/vB.\n\nExamples:\n> syscoin-cli syscoincreaterawnevmblob "versionhash" "data" 6 economical 25\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "syscoincreaterawnevmblob", "params": ["versionhash" "data" 6 economical 25]}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h3",{id:"listnevmblobdata"},(0,i.kt)("inlineCode",{parentName:"h3"},"listnevmblobdata")),(0,i.kt)("p",null,"Retrieve a list of blobs from the UTXO cache."),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'listnevmblobdata ( count from {"getdata":bool} )\n\nArguments:\n1. count (numeric, optional, default=10) The number of results to return.\n2. from (numeric, optional, default=0) The number of results to skip.\n3. options (json object, optional) A json object with options to filter results.\n {\n "getdata": bool, (boolean, optional) Return data from blob\n }\n\nResult:\n[ (json array)\n { (json object)\n "versionhash" : "hex", (string) The version hash of the NEVM blob\n "datasize" : n, (numeric) Size of data blob in bytes\n "data" : "hex" (string) Blob data if getdata is true\n },\n ...\n]\n\nExamples:\n> syscoin-cli listnevmblobdata 0\n> syscoin-cli listnevmblobdata 10 10\n> syscoin-cli listnevmblobdata 0 0 \'{"getdata":true}\'\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "listnevmblobdata", "params": [0, 0, \'{"getdata":false}\']}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h3",{id:"getnevmblobdata"},(0,i.kt)("inlineCode",{parentName:"h3"},"getnevmblobdata")),(0,i.kt)("p",null,"Retrieve a specific blob from the cache by version hash or transaction id"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'getnevmblobdata "versionhash_or_txid" ( getdata )\n\nArguments:\n1. versionhash_or_txid (string, required) The version hash or txid of the NEVM blob\n2. getdata (boolean, optional) Optional, retrieve the blob data\n\nExamples:\n> syscoin-cli getnevmblobdata \n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "getnevmblobdata", "params": []}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h2",{id:"how-to-run-a-bitcoinda-archive-service"},"How to run a BitcoinDA archive service"),(0,i.kt)("p",null,"As mentioned previously, with BitcoinDA the focus is DA. Archiving is left non-determined. However, tools are available."),(0,i.kt)("p",null,"Syscoin's Sentinel implementation provides the means to both store and retrieve BitcoinDA data blobs. Archivers may also employ other means at their discretion. If decentralized archiving is a priority, there are networks that can be custom-integrated with BitcoinDA, such a KYVE."),(0,i.kt)("p",null,"Syscoin ",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/syscoin/sentinel"},"Sentinel"))," includes a BitcoinDA archive client/server with out-of-the-box support for Filecoin/Lighthouse and Cloudflare R2 (supply your API keys)",(0,i.kt)("br",{parentName:"p"}),"\n","This is relatively easy to set up. Refer to the ",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/syscoin/sentinel#poda"},"instructions"))," on GitHub."))}d.isMDXComponent=!0},6023:(e,t,a)=>{a.d(t,{Z:()=>n});const n=a.p+"assets/images/diagram_PoDA-3f2b5cde651f01704965278bca6b785b.png"}}]); \ No newline at end of file diff --git a/assets/js/e0833ef8.6e907f0b.js b/assets/js/e0833ef8.6e907f0b.js new file mode 100644 index 00000000..2ba1bb9d --- /dev/null +++ b/assets/js/e0833ef8.6e907f0b.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[540],{98338:(e,t,a)=>{a.d(t,{Zo:()=>d,kt:()=>u});var n=a(76687);function i(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function o(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function r(e){for(var t=1;t=0||(i[a]=e[a]);return i}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var l=n.createContext({}),c=function(e){var t=n.useContext(l),a=t;return e&&(a="function"==typeof e?e(t):r(r({},t),e)),a},d=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},h="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var a=e.components,i=e.mdxType,o=e.originalType,l=e.parentName,d=s(e,["components","mdxType","originalType","parentName"]),h=c(a),p=i,u=h["".concat(l,".").concat(p)]||h[p]||m[p]||o;return a?n.createElement(u,r(r({ref:t},d),{},{components:a})):n.createElement(u,r({ref:t},d))}));function u(e,t){var a=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var o=a.length,r=new Array(o);r[0]=p;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[h]="string"==typeof e?e:i,r[1]=s;for(var c=2;c{a.r(t),a.d(t,{default:()=>d,frontMatter:()=>o,metadata:()=>r,toc:()=>s});var n=a(87250),i=(a(76687),a(98338));const o={},r={unversionedId:"tech/poda",id:"tech/poda",isDocsHomePage:!1,title:"BitcoinDA (Data Availability on Layer 1)",description:"Overview",source:"@site/docs/tech/poda.mdx",sourceDirName:"tech",slug:"/tech/poda",permalink:"/docs/tech/poda",version:"current",frontMatter:{},sidebar:"tutorialSidebar",previous:{title:"Notary and Business Rulesets",permalink:"/docs/tech/notary"},next:{title:"Rollux",permalink:"/docs/tech/rollux"}},s=[{value:"Overview",id:"overview",children:[]},{value:"Sample BitcoinDA transaction",id:"sample-bitcoinda-transaction",children:[]},{value:"How to interact with BitcoinDA",id:"how-to-interact-with-bitcoinda",children:[{value:"syscoincreatenevmblob",id:"syscoincreatenevmblob",children:[]},{value:"syscoincreaterawnevmblob",id:"syscoincreaterawnevmblob",children:[]},{value:"listnevmblobdata",id:"listnevmblobdata",children:[]},{value:"getnevmblobdata",id:"getnevmblobdata",children:[]}]},{value:"How to run a BitcoinDA archive service",id:"how-to-run-a-bitcoinda-archive-service",children:[]}],l={toc:s},c="wrapper";function d(e){let{components:t,...o}=e;return(0,i.kt)(c,(0,n.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"overview"},"Overview"),(0,i.kt)("p",null,"Data availability is required to exist within the security domain of Layer 1 in order for rollups to properly serve critical financial applications by securing users\u2019 ability to exit to L1. Syscoin\u2019s L1 DA solution is called BitcoinDA. BitcoinDA differs from Ethereum\u2019s Proto-Danksharding, and Celestia, in how data is stored, presented, pruned, and how fees are calculated. BitcoinDA provides characteristics that make it a valuable alternative to Ethereum\u2019s work-in-progress data availability solution, Proto-Danksharding."),(0,i.kt)("p",null,"BitcoinDA\u2019s advantages can be summarized as:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Cheaper transactions"),(0,i.kt)("li",{parentName:"ul"},"No data sharding required"),(0,i.kt)("li",{parentName:"ul"},"Greater data throughput with efficient Keccak data blobs"),(0,i.kt)("li",{parentName:"ul"},"Secured by Bitcoin\u2019s own PoW plus Syscoin's finality"),(0,i.kt)("li",{parentName:"ul"},"More resilient to network-based outages/censorship"),(0,i.kt)("li",{parentName:"ul"},"Simpler data fee market based on Syscoin\u2019s UTXO fee market"),(0,i.kt)("li",{parentName:"ul"},"Nakamoto Assumption: Only one honest node is needed to guarantee data")),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"BitcoinDA's design is based on Syscoin's original PoDA (proof of data availability), which is a separation of concerns between data availability and data archiving with the protocol's purpose being the former.")),(0,i.kt)("div",{className:"admonition admonition-info alert alert--info"},(0,i.kt)("div",{parentName:"div",className:"admonition-heading"},(0,i.kt)("h5",{parentName:"div"},(0,i.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,i.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"14",height:"16",viewBox:"0 0 14 16"},(0,i.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M7 2.3c3.14 0 5.7 2.56 5.7 5.7s-2.56 5.7-5.7 5.7A5.71 5.71 0 0 1 1.3 8c0-3.14 2.56-5.7 5.7-5.7zM7 1C3.14 1 0 4.14 0 8s3.14 7 7 7 7-3.14 7-7-3.14-7-7-7zm1 3H6v5h2V4zm0 6H6v2h2v-2z"}))),"info")),(0,i.kt)("div",{parentName:"div",className:"admonition-content"},(0,i.kt)("p",{parentName:"div"},(0,i.kt)("strong",{parentName:"p"},"Purpose of BitcoinDA")," "),(0,i.kt)("ul",{parentName:"div"},(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Deterministically ensure and prove that data has been placed within the commons and that the public was given a sufficient and defined opportunity to archive it.")),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("strong",{parentName:"li"},"Provide an on-chain hash necessary to verify the integrity of any archived data at a later time, and the option of custom hashes for other purposes a user might implement on top."))))),(0,i.kt)("p",null,"With BitcoinDA, by default, a Keccak256 hash of the full data blob is stored on Layer 1, while an assumption is made that at least one honest party in the world will archive the blob within at least a six-hour window of time - similar to the honesty assumption made when syncing a Bitcoin node (at least one honest node). After this window of time, the blob is pruned from the network's cache while its hash remains on-chain."),(0,i.kt)("p",null,"Validium (fully offchain DA) is also available as an alternative to BitcoinDA for less-critical applications where the focus might be on even lower cost and higher throughput by trading-off Layer 1 data security. However, in the case of Syscoin PoDA, Layer 1 data security is quite affordable; archivers store full data off-chain while you gain the security of an on-chain hash."),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"img",src:a(6023).Z})),(0,i.kt)("h2",{id:"sample-bitcoinda-transaction"},"Sample BitcoinDA transaction"),(0,i.kt)("p",null,"This transaction was submitted by Rollux L2 to the Syscoin Native (UTXO) Mainnet.",(0,i.kt)("br",{parentName:"p"}),"\n",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://blockbook.syscoin.org/tx/8de8bf84a1c55a06ad2d10ee10e036e51d122d02ded0a57ebddfd1da640aebc6"},"https://blockbook.syscoin.org/tx/8de8bf84a1c55a06ad2d10ee10e036e51d122d02ded0a57ebddfd1da640aebc6"))," "),(0,i.kt)("p",null,"Note: The version hash is visible in the raw transaction data as scriptPubKey.asm: \u201cOP_RETURN 20",(0,i.kt)("strong",{parentName:"p"},"e76700ef2ceab4e1f71af30a1fcf0662eedbb932aa66285ac30dbca46256e7d4"),"\u201d"),(0,i.kt)("p",null,"The hash of the data blob is stored on-chain as seen above in boldened portion of the sample's OP_RETURN. This should be used to prove the integrity of archived data at any future time."),(0,i.kt)("h2",{id:"how-to-interact-with-bitcoinda"},"How to interact with BitcoinDA"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Syscoin Core (>=v4.4) provides an RPC interface that enables use of the BitcoinDA protocol")),(0,i.kt)("p",null,"Once submitted, the transaction with version hash is stored onchain in the next available block, while the full data blob is made publicly available within the native chain\u2019s cache for a period of six hours of finality before being pruned. As long as the blob is cached, archiving services can access and store it. In the event that sufficient finality is absent, BitcoinDA will retain blobs in the cache until aforementioned finality threshold is met. This helps ensure published data is given proper guarantees to solve fisherman's dilemma even during adverse network conditions. "),(0,i.kt)("h3",{id:"syscoincreatenevmblob"},(0,i.kt)("inlineCode",{parentName:"h3"},"syscoincreatenevmblob")),(0,i.kt)("p",null,"Submit data blob with auto-generated Keccak256 versionHash (recommended)"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'syscoincreatenevmblob "data" ( overwrite_existing conf_target "estimate_mode" fee_rate )\n\nArguments:\n1. data (string, required) blob in hex\n2. overwrite_existing (boolean, optional, default=true) true to overwrite an existing blob if it exists, false to return versionhash of data on duplicate.\n3. conf_target (numeric, optional, default=wallet -txconfirmtarget) Confirmation target in blocks\n4. estimate_mode (string, optional, default="unset") The fee estimate mode, must be one of (case insensitive):\n "unset"\n "economical"\n "conservative"\n5. fee_rate (numeric or string, optional, default=not set, fall back to wallet fee estimation) Specify a fee rate in sat/vB.\n\nExamples:\n> syscoin-cli syscoincreatenevmblob "data"\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "syscoincreatenevmblob", "params": ["data"]}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,i.kt)("div",{parentName:"div",className:"admonition-heading"},(0,i.kt)("h5",{parentName:"div"},(0,i.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,i.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,i.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,i.kt)("div",{parentName:"div",className:"admonition-content"},(0,i.kt)("p",{parentName:"div"},"You can extend the TTL (time-to-live) of a BitcoinDA blob for another six hours by resubmitting the same exact blob with the ",(0,i.kt)("inlineCode",{parentName:"p"},"overwrite_existing")," flag set to TRUE."))),(0,i.kt)("h3",{id:"syscoincreaterawnevmblob"},(0,i.kt)("inlineCode",{parentName:"h3"},"syscoincreaterawnevmblob")),(0,i.kt)("p",null,"Submit data blob with custom (user-specified) versionHash. This might be useful if you wish to use a different hash algorithm or implement some custom commitment scheme as a layer on top of BitcoinDA. Otherwise, it is best to stick with the ",(0,i.kt)("inlineCode",{parentName:"p"},"syscoincreatenevmblob")," standard."),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'syscoincreaterawnevmblob "versionhash" "data" ( conf_target "estimate_mode" fee_rate )\n\nArguments:\n1. versionhash (string, required) Version hash of the blob\n2. data (string, required) data in hex\n3. conf_target (numeric, optional, default=wallet -txconfirmtarget) Confirmation target in blocks\n4. estimate_mode (string, optional, default="unset") The fee estimate mode, must be one of (case insensitive):\n "unset"\n "economical"\n "conservative"\n5. fee_rate (numeric or string, optional, default=not set, fall back to wallet fee estimation) Specify a fee rate in sat/vB.\n\nExamples:\n> syscoin-cli syscoincreaterawnevmblob "versionhash" "data" 6 economical 25\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "syscoincreaterawnevmblob", "params": ["versionhash" "data" 6 economical 25]}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h3",{id:"listnevmblobdata"},(0,i.kt)("inlineCode",{parentName:"h3"},"listnevmblobdata")),(0,i.kt)("p",null,"Retrieve a list of blobs from the UTXO cache."),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'listnevmblobdata ( count from {"getdata":bool} )\n\nArguments:\n1. count (numeric, optional, default=10) The number of results to return.\n2. from (numeric, optional, default=0) The number of results to skip.\n3. options (json object, optional) A json object with options to filter results.\n {\n "getdata": bool, (boolean, optional) Return data from blob\n }\n\nResult:\n[ (json array)\n { (json object)\n "versionhash" : "hex", (string) The version hash of the NEVM blob\n "datasize" : n, (numeric) Size of data blob in bytes\n "data" : "hex" (string) Blob data if getdata is true\n },\n ...\n]\n\nExamples:\n> syscoin-cli listnevmblobdata 0\n> syscoin-cli listnevmblobdata 10 10\n> syscoin-cli listnevmblobdata 0 0 \'{"getdata":true}\'\n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "listnevmblobdata", "params": [0, 0, \'{"getdata":false}\']}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h3",{id:"getnevmblobdata"},(0,i.kt)("inlineCode",{parentName:"h3"},"getnevmblobdata")),(0,i.kt)("p",null,"Retrieve a specific blob from the cache by version hash or transaction id"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-text"},'getnevmblobdata "versionhash_or_txid" ( getdata )\n\nArguments:\n1. versionhash_or_txid (string, required) The version hash or txid of the NEVM blob\n2. getdata (boolean, optional) Optional, retrieve the blob data\n\nExamples:\n> syscoin-cli getnevmblobdata \n> curl --user myusername --data-binary \'{"jsonrpc": "1.0", "id": "curltest", "method": "getnevmblobdata", "params": []}\' -H \'content-type: text/plain;\' http://127.0.0.1:8370/\n')),(0,i.kt)("h2",{id:"how-to-run-a-bitcoinda-archive-service"},"How to run a BitcoinDA archive service"),(0,i.kt)("p",null,"As mentioned previously, with BitcoinDA the focus is DA. Archiving is left non-determined. However, tools are available."),(0,i.kt)("p",null,"Syscoin's Sentinel implementation provides the means to both store and retrieve BitcoinDA data blobs. Archivers may also employ other means at their discretion. If decentralized archiving is a priority, there are networks that can be custom-integrated with BitcoinDA, such a KYVE."),(0,i.kt)("p",null,"Syscoin ",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/syscoin/sentinel"},"Sentinel"))," includes a BitcoinDA archive client/server with out-of-the-box support for Filecoin/Lighthouse and Cloudflare R2 (supply your API keys)",(0,i.kt)("br",{parentName:"p"}),"\n","This is relatively easy to set up. Refer to the ",(0,i.kt)("strong",{parentName:"p"},(0,i.kt)("a",{parentName:"strong",href:"https://github.com/syscoin/sentinel#poda"},"instructions"))," on GitHub."))}d.isMDXComponent=!0},6023:(e,t,a)=>{a.d(t,{Z:()=>n});const n=a.p+"assets/images/diagram_PoDA-3f2b5cde651f01704965278bca6b785b.png"}}]); \ No newline at end of file diff --git a/assets/js/e1644855.6e31e36e.js b/assets/js/e1644855.6e31e36e.js deleted file mode 100644 index 232a2892..00000000 --- a/assets/js/e1644855.6e31e36e.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[1234],{98338:(e,t,i)=>{i.d(t,{Zo:()=>p,kt:()=>y});var n=i(76687);function r(e,t,i){return t in e?Object.defineProperty(e,t,{value:i,enumerable:!0,configurable:!0,writable:!0}):e[t]=i,e}function o(e,t){var i=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),i.push.apply(i,n)}return i}function a(e){for(var t=1;t=0||(r[i]=e[i]);return r}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,i)&&(r[i]=e[i])}return r}var l=n.createContext({}),c=function(e){var t=n.useContext(l),i=t;return e&&(i="function"==typeof e?e(t):a(a({},t),e)),i},p=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},u="mdxType",d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},h=n.forwardRef((function(e,t){var i=e.components,r=e.mdxType,o=e.originalType,l=e.parentName,p=s(e,["components","mdxType","originalType","parentName"]),u=c(i),h=r,y=u["".concat(l,".").concat(h)]||u[h]||d[h]||o;return i?n.createElement(y,a(a({ref:t},p),{},{components:i})):n.createElement(y,a({ref:t},p))}));function y(e,t){var i=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var o=i.length,a=new Array(o);a[0]=h;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[u]="string"==typeof e?e:r,a[1]=s;for(var c=2;c{i.r(t),i.d(t,{default:()=>p,frontMatter:()=>o,metadata:()=>a,toc:()=>s});var n=i(87250),r=(i(76687),i(98338));const o={sidebar_position:1},a={unversionedId:"intro/nutshell",id:"intro/nutshell",isDocsHomePage:!1,title:"Syscoin in a Nutshell",description:"Mission",source:"@site/docs/intro/nutshell.mdx",sourceDirName:"intro",slug:"/intro/nutshell",permalink:"/docs/intro/nutshell",version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"tutorialSidebar",next:{title:"A More Detailed Overview",permalink:"/docs/intro/syscoin-what"}},s=[{value:"Mission",id:"mission",children:[]},{value:"The Blockchain Protocol",id:"the-blockchain-protocol",children:[]},{value:"zkDA and Trustless Interoperability",id:"zkda-and-trustless-interoperability",children:[]},{value:"Decentralized Finality without Slashing",id:"decentralized-finality-without-slashing",children:[]},{value:"Why $SYS?",id:"why-sys",children:[]},{value:"Diagram",id:"diagram",children:[]}],l={toc:s},c="wrapper";function p(e){let{components:t,...o}=e;return(0,r.kt)(c,(0,n.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h2",{id:"mission"},"Mission"),(0,r.kt)("p",null,"An open source community dedicated to scaling Bitcoin, especially its proof-of-work security, to meet global needs and emerging use-cases, while sticking as close as possible to Bitcoin's original ideals."),(0,r.kt)("p",null,"Syscoin's evolution across ten years of mainnet and the foresight reflected in its design mean the project has a head-start providing a comprehensive network and protocol for projects aiming to achieve Bitcoin L2. Join us!"),(0,r.kt)("h2",{id:"the-blockchain-protocol"},"The Blockchain Protocol"),(0,r.kt)("p",null,"Syscoin is a mainnet Bitcoin L2 that provides ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/poda"},"a data availability protocol that scales"),", making EVM and AltVM rollups on Bitcoin a reality. ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/merged-mining"},"Merge-mined")," by a majority Bitcoin's hashrate, Syscoin anchors rollups to Bitcoin's own proof-of-work and works with rollups\u2019 existing sequencer architectures. "),(0,r.kt)("p",null,"One such rollup is ",(0,r.kt)("a",{parentName:"p",href:"https://rollux.com"},"Rollux"),", an EVM-equivalent OPStack with 2 second blocktimes and negligible fees, which is live."),(0,r.kt)("h2",{id:"zkda-and-trustless-interoperability"},"zkDA and Trustless Interoperability"),(0,r.kt)("p",null,"Syscoin is currently pioneering ",(0,r.kt)("a",{parentName:"p",href:"https://syscoin.org/news/introducing-zkda"},"zkDA"),", an upcoming solution that will make Data Availability cross-chain interoperable through ZK light clients. This will make it easy for other blockchains to tap into Syscoin's DA and ultimately Bitcoin's PoW, and to trustlessly interoperate with other ecosystems that do the same."),(0,r.kt)("h2",{id:"decentralized-finality-without-slashing"},"Decentralized Finality without Slashing"),(0,r.kt)("p",null,"Data Availability and scaling it require preventing risks of impact from chain re-orgs. Syscoin solves this with a ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/finality"},"finality mechanism of multi-quorum chainlocks"),". This creates an additive security layer on top of Bitcoin's PoW. Served by 1,600 randomly selected ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/sentrynodes"},"Sentry nodes"),", this practically eliminates the risks of re-orgs, 51% attacks and selfish mining, without involving slashing."),(0,r.kt)("h2",{id:"why-sys"},"Why $SYS?"),(0,r.kt)("p",null,"Don't blow your finite BTC on gas fees! ",(0,r.kt)("a",{parentName:"p",href:"https://syscoin.org/get-sys"},"$SYS")," is a utility-focused native coin, based upon EIP-1559. SYS incentivizes Bitcoin miners to keep supporting Bitcoin indefinitely into the future despite diminishing BTC rewards. It also incentivizes Syscoin's Sentry nodes."),(0,r.kt)("h2",{id:"diagram"},"Diagram"),(0,r.kt)("p",null,(0,r.kt)("img",{alt:"img",src:i(16400).Z})))}p.isMDXComponent=!0},16400:(e,t,i)=>{i.d(t,{Z:()=>n});const n=i.p+"assets/images/diagram_SyscoinOverallDesign-82b321ac10a146b018bf18b1be2434ab.png"}}]); \ No newline at end of file diff --git a/assets/js/e1644855.f5540936.js b/assets/js/e1644855.f5540936.js new file mode 100644 index 00000000..52d9bbef --- /dev/null +++ b/assets/js/e1644855.f5540936.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunksys_docs=self.webpackChunksys_docs||[]).push([[1234],{98338:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>m});var i=n(76687);function r(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);t&&(i=i.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,i)}return n}function a(e){for(var t=1;t=0||(r[n]=e[n]);return r}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(i=0;i=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(r[n]=e[n])}return r}var l=i.createContext({}),c=function(e){var t=i.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):a(a({},t),e)),n},u=function(e){var t=c(e.components);return i.createElement(l.Provider,{value:t},e.children)},p="mdxType",d={inlineCode:"code",wrapper:function(e){var t=e.children;return i.createElement(i.Fragment,{},t)}},h=i.forwardRef((function(e,t){var n=e.components,r=e.mdxType,o=e.originalType,l=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),p=c(n),h=r,m=p["".concat(l,".").concat(h)]||p[h]||d[h]||o;return n?i.createElement(m,a(a({ref:t},u),{},{components:n})):i.createElement(m,a({ref:t},u))}));function m(e,t){var n=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var o=n.length,a=new Array(o);a[0]=h;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[p]="string"==typeof e?e:r,a[1]=s;for(var c=2;c{n.r(t),n.d(t,{default:()=>u,frontMatter:()=>o,metadata:()=>a,toc:()=>s});var i=n(87250),r=(n(76687),n(98338));const o={sidebar_position:1},a={unversionedId:"intro/nutshell",id:"intro/nutshell",isDocsHomePage:!1,title:"Syscoin in a Nutshell",description:"Mission",source:"@site/docs/intro/nutshell.mdx",sourceDirName:"intro",slug:"/intro/nutshell",permalink:"/docs/intro/nutshell",version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"tutorialSidebar",next:{title:"A More Detailed Overview",permalink:"/docs/intro/syscoin-what"}},s=[{value:"Mission",id:"mission",children:[]},{value:"The Blockchain Protocol",id:"the-blockchain-protocol",children:[]},{value:"Decentralized Finality without Slashing",id:"decentralized-finality-without-slashing",children:[]},{value:"Current Research & Development",id:"current-research--development",children:[]},{value:"Why $SYS?",id:"why-sys",children:[]},{value:"Diagram",id:"diagram",children:[]}],l={toc:s},c="wrapper";function u(e){let{components:t,...o}=e;return(0,r.kt)(c,(0,i.Z)({},l,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h2",{id:"mission"},"Mission"),(0,r.kt)("p",null,"An open source community dedicated to scaling Bitcoin, especially its proof-of-work security, to meet global needs and emerging use-cases, while sticking as close as possible to Bitcoin's original ideals."),(0,r.kt)("p",null,"Syscoin's evolution across ten years of mainnet and the foresight reflected in its design mean the project has a head-start providing a comprehensive network and protocol for projects aiming to achieve Bitcoin L2. Join us!"),(0,r.kt)("h2",{id:"the-blockchain-protocol"},"The Blockchain Protocol"),(0,r.kt)("p",null,"Syscoin is a mainnet Bitcoin L2 that provides ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/poda"},"a data availability protocol that scales"),", making EVM and AltVM rollups on Bitcoin a reality. ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/merged-mining"},"Merge-mined")," by a majority Bitcoin's hashrate, Syscoin anchors rollups to Bitcoin's own proof-of-work and works with rollups\u2019 existing sequencer architectures. "),(0,r.kt)("p",null,"One such rollup is ",(0,r.kt)("a",{parentName:"p",href:"https://rollux.com"},"Rollux"),", an EVM-equivalent OPStack with 2 second blocktimes and negligible fees, which is live."),(0,r.kt)("h2",{id:"decentralized-finality-without-slashing"},"Decentralized Finality without Slashing"),(0,r.kt)("p",null,"Data Availability and scaling it require preventing risks of impact from chain re-orgs. Syscoin solves this with a ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/finality"},"finality mechanism of multi-quorum chainlocks"),". This creates an additive security layer on top of Bitcoin's PoW. Served by 1,600 randomly selected ",(0,r.kt)("a",{parentName:"p",href:"/docs/tech/sentrynodes"},"Sentry nodes"),", this practically eliminates the risks of re-orgs, 51% attacks and selfish mining, without involving slashing."),(0,r.kt)("h2",{id:"current-research--development"},"Current Research & Development"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://syscoin.org/news/introducing-zkda"},"zkDA"),", an upcoming solution that will make Data Availability cross-chain interoperable through ZK light clients. This will make it easy for other blockchains to tap into Syscoin's DA and ultimately Bitcoin's PoW, and to trustlessly interoperate with other ecosystems that do the same."),(0,r.kt)("li",{parentName:"ul"},"SYS Labs and Syscoin Foundation R&D includes Bitcoin L0, crypto-economic security for every facet of Bitcoin L2 through Rollux, and a difficulty-based stBTC.")),(0,r.kt)("h2",{id:"why-sys"},"Why $SYS?"),(0,r.kt)("p",null,"Don't blow your finite BTC on gas fees! ",(0,r.kt)("a",{parentName:"p",href:"https://syscoin.org/get-sys"},"$SYS")," is a utility-focused native coin, based upon EIP-1559. SYS incentivizes Bitcoin miners to keep supporting Bitcoin indefinitely into the future despite diminishing BTC rewards. It also incentivizes Syscoin's Sentry nodes."),(0,r.kt)("h2",{id:"diagram"},"Diagram"),(0,r.kt)("p",null,"Objects colored gray are in research and development. All others are mainnet."),(0,r.kt)("p",null,(0,r.kt)("img",{alt:"img",src:n(16400).Z})))}u.isMDXComponent=!0},16400:(e,t,n)=>{n.d(t,{Z:()=>i});const i=n.p+"assets/images/diagram_SyscoinOverallDesign-77198a540dbcdd3a521218954402e779.png"}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.c6906c82.js b/assets/js/runtime~main.1f114642.js similarity index 56% rename from assets/js/runtime~main.c6906c82.js rename to assets/js/runtime~main.1f114642.js index 83b42355..ab71f70a 100644 --- a/assets/js/runtime~main.c6906c82.js +++ b/assets/js/runtime~main.1f114642.js @@ -1 +1 @@ -(()=>{"use strict";var e,a,d,c,t,r={},b={};function f(e){var a=b[e];if(void 0!==a)return a.exports;var d=b[e]={id:e,loaded:!1,exports:{}};return r[e].call(d.exports,d,d.exports,f),d.loaded=!0,d.exports}f.m=r,f.c=b,f.amdO={},e=[],f.O=(a,d,c,t)=>{if(!d){var r=1/0;for(i=0;i=t)&&Object.keys(f.O).every((e=>f.O[e](d[o])))?d.splice(o--,1):(b=!1,t0&&e[i-1][2]>t;i--)e[i]=e[i-1];e[i]=[d,c,t]},f.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return f.d(a,{a:a}),a},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,f.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var t=Object.create(null);f.r(t);var r={};a=a||[null,d({}),d([]),d(d)];for(var b=2&c&&e;"object"==typeof b&&!~a.indexOf(b);b=d(b))Object.getOwnPropertyNames(b).forEach((a=>r[a]=()=>e[a]));return r.default=()=>e,f.d(t,r),t},f.d=(e,a)=>{for(var d in a)f.o(a,d)&&!f.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:a[d]})},f.f={},f.e=e=>Promise.all(Object.keys(f.f).reduce(((a,d)=>(f.f[d](e,a),a)),[])),f.u=e=>"assets/js/"+({53:"935f2afb",373:"e67d531c",457:"da6e3234",540:"e0833ef8",605:"4e379c15",795:"eb7c48ea",917:"24866cdd",1174:"75d97c0d",1234:"e1644855",1636:"961dd717",1777:"626b2642",2555:"a991d789",3255:"af623beb",3640:"a0964cc0",3718:"c29fbac1",3856:"b2de18a9",3958:"52386b31",4250:"a2b80acb",4728:"7fb06139",4934:"41a4b76b",5522:"038b7bcf",5613:"5be3bbaa",5782:"186c746e",5823:"e12fa9e1",5921:"202fef56",6002:"45b38303",6428:"31d91691",6492:"ef6cd603",6886:"fbf3c524",7145:"3aeb0a06",7283:"7637bbfc",7850:"b3cf3865",7911:"da5928e5",7912:"d4f51590",7918:"17896441",7937:"ea313555",8249:"4b288558",8433:"4311ecdf",8474:"0c5fc6bd",8478:"eab5d44b",8596:"2c70be15",8638:"0f5337d7",8742:"3e93e8e5",8877:"38964cd2",9011:"eea8d354",9160:"75a64746",9272:"157b295e",9514:"1be78505",9526:"cd4e8672"}[e]||e)+"."+{53:"ff5e2820",373:"df471e7a",457:"c3eb9530",540:"03933a25",605:"8a6d0d6e",795:"f4cec051",873:"dcb3b37a",917:"22767f10",1174:"0bfcf8f1",1234:"6e31e36e",1331:"f83546b6",1636:"0796781d",1777:"2064a7ae",2555:"656e5f50",3255:"f2788168",3640:"53f30d9e",3718:"9d2105ba",3856:"773f4756",3958:"2f07665c",4250:"a4d21c57",4728:"2b376748",4934:"dda27f22",5522:"c48a5611",5613:"1137ca39",5782:"62cbfe48",5823:"589e3d7f",5921:"86a381e5",6002:"32f11449",6428:"cbb67586",6492:"17ddee6a",6525:"8b63c92a",6886:"83d07b7d",7145:"473c7048",7173:"a4764ef1",7283:"19c3b7d0",7850:"c32131fc",7911:"a44f4f99",7912:"81fe207b",7918:"ca213bda",7937:"e6e2a16d",8249:"1630bc3c",8433:"d788567a",8474:"cd81cc43",8478:"790ee453",8596:"48059a61",8638:"cd93decb",8742:"6823354f",8744:"36272c4b",8877:"a38aee09",9011:"96fd1a54",9160:"852bdcee",9272:"0447d80a",9514:"82418ef0",9526:"c6ccb788"}[e]+".js",f.miniCssF=e=>"assets/css/styles.8f3499ac.css",f.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),f.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),c={},t="sys-docs:",f.l=(e,a,d,r)=>{if(c[e])c[e].push(a);else{var b,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{b.onerror=b.onload=null,clearTimeout(u);var t=c[e];if(delete c[e],b.parentNode&&b.parentNode.removeChild(b),t&&t.forEach((e=>e(d))),a)return a(d)},u=setTimeout(l.bind(null,void 0,{type:"timeout",target:b}),12e4);b.onerror=l.bind(null,b.onerror),b.onload=l.bind(null,b.onload),o&&document.head.appendChild(b)}},f.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.nmd=e=>(e.paths=[],e.children||(e.children=[]),e),f.p="/",f.gca=function(e){return e={17896441:"7918","935f2afb":"53",e67d531c:"373",da6e3234:"457",e0833ef8:"540","4e379c15":"605",eb7c48ea:"795","24866cdd":"917","75d97c0d":"1174",e1644855:"1234","961dd717":"1636","626b2642":"1777",a991d789:"2555",af623beb:"3255",a0964cc0:"3640",c29fbac1:"3718",b2de18a9:"3856","52386b31":"3958",a2b80acb:"4250","7fb06139":"4728","41a4b76b":"4934","038b7bcf":"5522","5be3bbaa":"5613","186c746e":"5782",e12fa9e1:"5823","202fef56":"5921","45b38303":"6002","31d91691":"6428",ef6cd603:"6492",fbf3c524:"6886","3aeb0a06":"7145","7637bbfc":"7283",b3cf3865:"7850",da5928e5:"7911",d4f51590:"7912",ea313555:"7937","4b288558":"8249","4311ecdf":"8433","0c5fc6bd":"8474",eab5d44b:"8478","2c70be15":"8596","0f5337d7":"8638","3e93e8e5":"8742","38964cd2":"8877",eea8d354:"9011","75a64746":"9160","157b295e":"9272","1be78505":"9514",cd4e8672:"9526"}[e]||e,f.p+f.u(e)},(()=>{var e={1303:0,532:0};f.f.j=(a,d)=>{var c=f.o(e,a)?e[a]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var t=new Promise(((d,t)=>c=e[a]=[d,t]));d.push(c[2]=t);var r=f.p+f.u(a),b=new Error;f.l(r,(d=>{if(f.o(e,a)&&(0!==(c=e[a])&&(e[a]=void 0),c)){var t=d&&("load"===d.type?"missing":d.type),r=d&&d.target&&d.target.src;b.message="Loading chunk "+a+" failed.\n("+t+": "+r+")",b.name="ChunkLoadError",b.type=t,b.request=r,c[1](b)}}),"chunk-"+a,a)}},f.O.j=a=>0===e[a];var a=(a,d)=>{var c,t,r=d[0],b=d[1],o=d[2],n=0;if(r.some((a=>0!==e[a]))){for(c in b)f.o(b,c)&&(f.m[c]=b[c]);if(o)var i=o(f)}for(a&&a(d);n{"use strict";var e,a,c,d,t,r={},b={};function f(e){var a=b[e];if(void 0!==a)return a.exports;var c=b[e]={id:e,loaded:!1,exports:{}};return r[e].call(c.exports,c,c.exports,f),c.loaded=!0,c.exports}f.m=r,f.c=b,f.amdO={},e=[],f.O=(a,c,d,t)=>{if(!c){var r=1/0;for(i=0;i=t)&&Object.keys(f.O).every((e=>f.O[e](c[o])))?c.splice(o--,1):(b=!1,t0&&e[i-1][2]>t;i--)e[i]=e[i-1];e[i]=[c,d,t]},f.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return f.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,f.t=function(e,d){if(1&d&&(e=this(e)),8&d)return e;if("object"==typeof e&&e){if(4&d&&e.__esModule)return e;if(16&d&&"function"==typeof e.then)return e}var t=Object.create(null);f.r(t);var r={};a=a||[null,c({}),c([]),c(c)];for(var b=2&d&&e;"object"==typeof b&&!~a.indexOf(b);b=c(b))Object.getOwnPropertyNames(b).forEach((a=>r[a]=()=>e[a]));return r.default=()=>e,f.d(t,r),t},f.d=(e,a)=>{for(var c in a)f.o(a,c)&&!f.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},f.f={},f.e=e=>Promise.all(Object.keys(f.f).reduce(((a,c)=>(f.f[c](e,a),a)),[])),f.u=e=>"assets/js/"+({53:"935f2afb",373:"e67d531c",457:"da6e3234",540:"e0833ef8",605:"4e379c15",795:"eb7c48ea",917:"24866cdd",1174:"75d97c0d",1234:"e1644855",1636:"961dd717",1777:"626b2642",2555:"a991d789",3255:"af623beb",3640:"a0964cc0",3718:"c29fbac1",3856:"b2de18a9",3958:"52386b31",4250:"a2b80acb",4728:"7fb06139",4934:"41a4b76b",5522:"038b7bcf",5613:"5be3bbaa",5782:"186c746e",5823:"e12fa9e1",5921:"202fef56",6002:"45b38303",6428:"31d91691",6492:"ef6cd603",6886:"fbf3c524",7145:"3aeb0a06",7283:"7637bbfc",7850:"b3cf3865",7911:"da5928e5",7912:"d4f51590",7918:"17896441",7937:"ea313555",8249:"4b288558",8433:"4311ecdf",8474:"0c5fc6bd",8478:"eab5d44b",8596:"2c70be15",8638:"0f5337d7",8742:"3e93e8e5",8877:"38964cd2",9011:"eea8d354",9160:"75a64746",9272:"157b295e",9514:"1be78505",9526:"cd4e8672"}[e]||e)+"."+{53:"ff5e2820",373:"df471e7a",457:"c3eb9530",540:"6e907f0b",605:"8a6d0d6e",795:"f4cec051",873:"dcb3b37a",917:"22767f10",1174:"0bfcf8f1",1234:"f5540936",1331:"f83546b6",1636:"0796781d",1777:"2064a7ae",2555:"656e5f50",3255:"f2788168",3640:"53f30d9e",3718:"9d2105ba",3856:"773f4756",3958:"2f07665c",4250:"a4d21c57",4728:"2b376748",4934:"dda27f22",5522:"c48a5611",5613:"1137ca39",5782:"62cbfe48",5823:"589e3d7f",5921:"86a381e5",6002:"32f11449",6428:"cbb67586",6492:"17ddee6a",6525:"8b63c92a",6886:"83d07b7d",7145:"473c7048",7173:"a4764ef1",7283:"6f23bdb0",7850:"c32131fc",7911:"a44f4f99",7912:"81fe207b",7918:"ca213bda",7937:"e6e2a16d",8249:"1630bc3c",8433:"d788567a",8474:"cd81cc43",8478:"790ee453",8596:"48059a61",8638:"cd93decb",8742:"6823354f",8744:"36272c4b",8877:"a38aee09",9011:"96fd1a54",9160:"852bdcee",9272:"0447d80a",9514:"82418ef0",9526:"c6ccb788"}[e]+".js",f.miniCssF=e=>"assets/css/styles.8f3499ac.css",f.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),f.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),d={},t="sys-docs:",f.l=(e,a,c,r)=>{if(d[e])d[e].push(a);else{var b,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{b.onerror=b.onload=null,clearTimeout(u);var t=d[e];if(delete d[e],b.parentNode&&b.parentNode.removeChild(b),t&&t.forEach((e=>e(c))),a)return a(c)},u=setTimeout(l.bind(null,void 0,{type:"timeout",target:b}),12e4);b.onerror=l.bind(null,b.onerror),b.onload=l.bind(null,b.onload),o&&document.head.appendChild(b)}},f.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.nmd=e=>(e.paths=[],e.children||(e.children=[]),e),f.p="/",f.gca=function(e){return e={17896441:"7918","935f2afb":"53",e67d531c:"373",da6e3234:"457",e0833ef8:"540","4e379c15":"605",eb7c48ea:"795","24866cdd":"917","75d97c0d":"1174",e1644855:"1234","961dd717":"1636","626b2642":"1777",a991d789:"2555",af623beb:"3255",a0964cc0:"3640",c29fbac1:"3718",b2de18a9:"3856","52386b31":"3958",a2b80acb:"4250","7fb06139":"4728","41a4b76b":"4934","038b7bcf":"5522","5be3bbaa":"5613","186c746e":"5782",e12fa9e1:"5823","202fef56":"5921","45b38303":"6002","31d91691":"6428",ef6cd603:"6492",fbf3c524:"6886","3aeb0a06":"7145","7637bbfc":"7283",b3cf3865:"7850",da5928e5:"7911",d4f51590:"7912",ea313555:"7937","4b288558":"8249","4311ecdf":"8433","0c5fc6bd":"8474",eab5d44b:"8478","2c70be15":"8596","0f5337d7":"8638","3e93e8e5":"8742","38964cd2":"8877",eea8d354:"9011","75a64746":"9160","157b295e":"9272","1be78505":"9514",cd4e8672:"9526"}[e]||e,f.p+f.u(e)},(()=>{var e={1303:0,532:0};f.f.j=(a,c)=>{var d=f.o(e,a)?e[a]:void 0;if(0!==d)if(d)c.push(d[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var t=new Promise(((c,t)=>d=e[a]=[c,t]));c.push(d[2]=t);var r=f.p+f.u(a),b=new Error;f.l(r,(c=>{if(f.o(e,a)&&(0!==(d=e[a])&&(e[a]=void 0),d)){var t=c&&("load"===c.type?"missing":c.type),r=c&&c.target&&c.target.src;b.message="Loading chunk "+a+" failed.\n("+t+": "+r+")",b.name="ChunkLoadError",b.type=t,b.request=r,d[1](b)}}),"chunk-"+a,a)}},f.O.j=a=>0===e[a];var a=(a,c)=>{var d,t,r=c[0],b=c[1],o=c[2],n=0;if(r.some((a=>0!==e[a]))){for(d in b)f.o(b,d)&&(f.m[d]=b[d]);if(o)var i=o(f)}for(a&&a(c);n Blockbook API | Syscoin Docs - +

Blockbook API

Blockbook provides REST, websocket and socket.io API to the indexed blockchain.

There are two versions of provided API.

API V2#

API V2 is the current version of API. It can be used with all coin types that Blockbook supports. API V2 can be accessed using REST and websocket interface.

Common principles used in API V2:

  • all amounts are transferred as strings, in the lowest denomination (satoshis, wei, ...), without decimal point
  • empty fields are omitted. Empty field is a string of value null or "", a number of value 0, an object of value null or an array without elements. The reason for this is that the interface serves many different coins which use only subset of the fields. Sometimes this principle can lead to slightly confusing results, for example when transaction version is 0, the field version is omitted.

REST API#

The following methods are supported:

Status page#

Status page returns current status of Blockbook and connected backend.

GET /api

Response:

{
"blockbook": {
"coin": "Bitcoin",
"host": "blockbook",
"version": "0.3.5",
"gitCommit": "3d9ad91",
"buildTime": "2019-05-17T14:34:00+00:00",
"syncMode": true,
"initialSync": false,
"inSync": true,
"bestHeight": 577261,
"lastBlockTime": "2019-05-22T18:03:33.547762973+02:00",
"inSyncMempool": true,
"lastMempoolTime": "2019-05-22T18:10:10.27929383+02:00",
"mempoolSize": 17348,
"decimals": 8,
"dbSize": 191887866502,
"about": "Blockbook - blockchain indexer for Trezor wallet https://trezor.io/. Do not use for any other purpose."
},
"backend": {
"chain": "main",
"blocks": 577261,
"headers": 577261,
"bestBlockHash": "0000000000000000000ca8c902aa58b3118a7f35d093e25a07f17bcacd91cabf",
"difficulty": "6704632680587.417",
"sizeOnDisk": 250504188580,
"version": "180000",
"subversion": "/Satoshi:0.18.0/",
"protocolVersion": "70015",
"timeOffset": 0,
"warnings": ""
}
}

Get block hash#

GET /api/v2/block-index/<block height>

Response:

{
"blockHash": "ed8f3af8c10ca70a136901c6dd3adf037f0aea8a93fbe9e80939214034300f1e"
}

Note: Blockbook always follows the main chain of the backend it is attached to. See notes on Get Block below

Get transaction#

Get transaction returns "normalized" data about transaction, which has the same general structure for all supported coins. It does not return coin specific fields (for example information about Zcash shielded addresses).

GET /api/v2/tx/<txid>

Response for Bitcoin-type coins:

{
"txid": "9e2bc8fbd40af17a6564831f84aef0cab2046d4bad19e91c09d21bff2c851851",
"version": 1,
"vin": [
{
"txid": "f124e6999bf67e710b9e8a8ac4dbb08a64aa9c264120cf98793455e36a531615",
"vout": 2,
"sequence": 4294967295,
"n": 0,
"addresses": [
"DDhUv8JZGmSxKYV95NLnbRTUKni9cDZD3S"
],
"isAddress": true,
"value": "55795108999999",
"hex": "473...2c7ec77bb982"
}
],
"vout": [
{
"value": "55585679000000",
"n": 0,
"hex": "76a914feaca9d9fa7120c7c587c00c639bb18d40faadd388ac",
"addresses": [
"DUMh1rPrXTrCN2Z9EHsLPg7b78rACHB2h7"
],
"isAddress": true
},
{
"value": "209329999999",
"n": 1,
"hex": "76a914ea8984be785868391d92f49c14933f47c152ea0a88ac",
"addresses": [
"DSXDQ6rnwLX47WFRnemctoXPHA9pLMxqXn"
],
"isAddress": true
}
],
"blockHash": "78d1f3de899a10dd2e580704226ebf9508e95e1706f177fc9c31c47f245d2502",
"blockHeight": 2647927,
"confirmations": 1,
"blockTime": 1553088212,
"value": "55795008999999",
"valueIn": "55795108999999",
"fees": "100000000",
"hex": "0100000...0011000"
}

Response for Ethereum-type coins. There is always only one vin, only one vout, possibly an array of tokenTransfers and ethereumSpecific part. Note that tokenTransfers will also exist for any coins exposing a token interface including Ethereum and Syscoin. Missing is hex field:

{
"txid": "0xb78a36a4a0e7d708d595c3b193cace8f5b420e72e1f595a5387d87de509f0806",
"vin": [
{
"n": 0,
"addresses": [
"0x9c2e011c0ce0d75c2b62b9c5a0ba0a7456593803"
],
"isAddress": true
}
],
"vout": [
{
"value": "0",
"n": 0,
"addresses": [
"0xc32ae45504ee9482db99cfa21066a59e877bc0e6"
],
"isAddress": true
}
],
"blockHash": "0x39df7fb0893200e1e78c04f98691637a89b64e7a3edd96c16f2537e2fd56c414",
"blockHeight": 5241585,
"confirmations": 3,
"blockTime": 1553088337,
"value": "0",
"fees": "402501000000000",
"tokenTransfers": [
{
"type": "ERC20",
"from": "0x9c2e011c0ce0d75c2b62b9c5a0ba0a7456593803",
"to": "0x583cbbb8a8443b38abcc0c956bece47340ea1367",
"token": "0xc32ae45504ee9482db99cfa21066a59e877bc0e6",
"name": "Tangany Test Token",
"symbol": "TATETO",
"decimals": 18,
"value": "133800000"
}
],
"ethereumSpecific": {
"status": 1,
"nonce": 2830,
"gasLimit": 36591,
"gasUsed": 36591,
"gasPrice": "11000000000",
"data": "0xa9059cbb000000000000000000000000ba98d6a5"
}
}

A note about the blockTime field:

  • for already mined transaction (confirmations > 0), the field blockTime contains time of the block
  • for transactions in mempool (confirmations == 0), the field contains time when the running instance of Blockbook was first time notified about the transaction. This time may be different in different instances of Blockbook.

Get transaction specific#

Returns transaction data in the exact format as returned by backend, including all coin specific fields:

GET /api/v2/tx-specific/<txid>

Example response:

{
"hex": "040000808...8e6e73cb009",
"txid": "7a0a0ff6f67bac2a856c7296382b69151949878de6fb0d01a8efa197182b2913",
"overwintered": true,
"version": 4,
"versiongroupid": "892f2085",
"locktime": 0,
"expiryheight": 495680,
"vin": [],
"vout": [],
"vjoinsplit": [],
"valueBalance": 0,
"vShieldedSpend": [
{
"cv": "50258bfa65caa9f42f4448b9194840c7da73afc8159faf7358140bfd0f237962",
"anchor": "6beb3b64ecb30033a9032e1a65a68899917625d1fdd2540e70f19f3078f5dd9b",
"nullifier": "08e5717f6606af7c2b01206ff833eaa6383bb49c7451534b2e16d588956fd10a",
"rk": "36841a9be87a7022445b77f433cdd0355bbed498656ab399aede1e5285e9e4a2",
"proof": "aecf824dbae8eea863ec6...73878c37391f01df520aa",
"spendAuthSig": "65b9477cb1ec5da...1178fe402e5702c646945197108339609"
},
{
"cv": "a5aab3721e33d6d6360eabd21cbd07524495f202149abdc3eb30f245d503678c",
"anchor": "6beb3b64ecb30033a9032e1a65a68899917625d1fdd2540e70f19f3078f5dd9b",
"nullifier": "60e790d6d0e12e777fb2b18bc97cf42a92b1e47460e1bd0b0ffd294c23232cc9",
"rk": "2d741695e76351597712b4a04d2a4e108a116f376283d2d104219b86e2930117",
"proof": "a0c2a6fdcbba966b9894...3a9c3118b76c8e2352d524cbb44c02decaeda7",
"spendAuthSig": "feea902e01eac9ebd...b43b4af6b607ce5b0b38f708"
}
],
"vShieldedOutput": [
{
"cv": "23db384cde862f20238a1004e57ba18f114acabc7fd2ac029757f82af5bd4cab",
"cmu": "3ff5a5ff521fabefb5287fef4feb2642d69ead5fe18e6ac717cfd76a8d4088bc",
"ephemeralKey": "057ff6e059967784fa6ac34ad9ecfd9c0c0aba743b7cd444a65ecc32192d5870",
"encCiphertext": "a533d3b99b...a0204",
"outCiphertext": "4baabc15199504b1...c1ad6a",
"proof": "aa1fb2706cba5...1ec7e81f5deea90d4f57713f3b4fc8d636908235fa378ebf1"
}
],
"bindingSig": "bc018af8808387...5130bb382ad8e6e73cb009",
"blockhash": "0000000001c4aa394e796dd1b82e358f114535204f6f5b6cf4ad58dc439c47af",
"confirmations": 5222,
"time": 1552301566,
"blocktime": 1552301566
}

Get address#

Returns balances and transactions of an address. The returned transactions are sorted by block height, newest blocks first.

GET /api/v2/address/<address>[?page=<page>&pageSize=<size>&from=<block height>&to=<block height>&details=<basic|tokens|tokenBalances|txids|txs>&filter=<inputs|outputs|tokens|0|uint32>&contract=<contract address>]

The optional query parameters:

  • page: specifies page of returned transactions, starting from 1. If out of range, Blockbook returns the closest possible page.
  • pageSize: number of transactions returned by call (default and maximum 1000)
  • from, to: filter of the returned transactions from block height to block height (default no filter)
  • details: specifies level of details returned by request (default txids)
    • basic: return only address balances, without any transactions
    • tokens: basic + tokens belonging to the address (applicable only to some coins)
    • tokenBalances: basic + tokens with balances + belonging to the address (applicable only to some coins)
    • txids: tokenBalances + list of txids, subject to from, to filter and paging
    • txslight: tokenBalances + list of transaction with limited details (only data from index), subject to from, to filter and paging
    • txs: tokenBalances + list of transaction with details, subject to from, to filter and paging
  • filter: specifies what tokens (xpub addresses/tokens) are returned by the request (default nonzero)
    • inputs: Return transactions sending inputs to this xpub
    • outputs: Return transactions sending outputs to this xpub
    • =: Return specific numerical vout index
  • assetMask: What type of transactions to return (default all)
    • all: Returns all types of transactions, base and asset type. The assetMask will represent value of all values OR'ed together see below in = for the masks.
    • non-tokens: Return only base coin transactions no asset type. The assetMask will represent value of basecoin.
    • token-only: Return only asset type transactions no base coin type. The assetMask will represent value of assetactivate | assetupdate | assetsend | syscoinburntoallocation | assetallocationburntosyscoin | assetallocationburntoethereum | assetallocationmint | assetallocationsend.
    • token-transfers: Return only assetallocationsend type transactions. The assetMask will represent value of assetallocationsend.
    • non-token-transfers: Return any transactions not of type assetallocationsend. The assetMask will represent value of token-only &^ token-transfers
    • =: Apply a custom numerical mask which is a bitmask of the following values:
      • basecoin: 1
      • assetallocationsend: 2
      • syscoinburntoallocation: 4
      • assetallocationburntosyscoin: 8
      • assetallocationburntoethereum: 16
      • assetallocationmint: 32
      • assetupdate: 64
      • assetsend: 128
      • assetactivate: 256
  • contract: return only transactions which affect specified contract or asset (applicable only to Ethereum and Syscoin)

Response:

{
"page": 1,
"totalPages": 1,
"itemsOnPage": 1000,
"address": "D5Z7XrtJNg7hAtznSDMXvfiFmMYphwuWz7",
"balance": "2432468097999991",
"totalReceived": "3992283916999979",
"totalSent": "1559815818999988",
"unconfirmedBalance": "0",
"unconfirmedTxs": 0,
"txs": 3,
"txids": [
"461dd46d5d6f56d765f82e60e6bf0727a3a1d1cb8c4144373d805b152a21d308",
"bdb5b47603c5d174eae3384c368068c8e9d2183b398ed0e31d125defa4447a10",
"5c1d2686d70d82bd8e84b5d3dc4bd0e8485e28cdc865336db6a5e40b2098277d"
]
}

Get xpub#

Returns balances and transactions of an xpub, applicable only for Bitcoin-type coins.

Blockbook supports BIP44, BIP49 and BIP84 derivation schemes. It expects xpub at level 3 derivation path, i.e. m/purpose'/coin_type'/account'/. Blockbook completes the change/address_index part of the path when deriving addresses.

The BIP version is determined by the prefix of the xpub. The prefixes for each coin are defined by fields xpub_magic, xpub_magic_segwit_p2sh, xpub_magic_segwit_native in the trezor-common library. If the prefix is not recognized, Blockbook defaults to BIP44 derivation scheme.

The returned transactions are sorted by block height, newest blocks first.

GET /api/v2/xpub/<xpub>[?page=<page>&pageSize=<size>&from=<block height>&to=<block height>&details=<basic|tokens|tokenBalances|txids|txs>&tokens=<nonzero|used|derived>&filter=<inputs|outputs|tokens|0|uint32>]

The optional query parameters:

  • page: specifies page of returned transactions, starting from 1. If out of range, Blockbook returns the closest possible page. Tokens are only returned for coins that have token platforms (Syscoin).
  • pageSize: number of transactions returned by call (default and maximum 1000)
  • from, to: filter of the returned transactions from block height to block height (default no filter)
  • details: specifies level of details returned by request (default txids)
    • basic: return only xpub balances, without any derived addresses and transactions
    • tokens: basic + tokens (addresses/tokens) derived from the xpub, subject to tokens parameter
    • tokenBalances: basic + tokens (addresses/tokens) derived from the xpub with balances, subject to tokens parameter
    • txids: tokenBalances + list of txids, subject to from, to filter and paging
    • txs: tokenBalances + list of transaction with details, subject to from, to filter and paging
  • tokens: specifies what tokens (xpub addresses/tokens) are returned by the request (default nonzero)
    • nonzero: return only addresses/tokens with nonzero balance
    • used: return addresses/tokens with at least one transaction
    • derived: return all derived addresses/tokens
  • filter: specifies what tokens (xpub addresses/tokens) are returned by the request (default nonzero)
    • inputs: Return transactions sending inputs to this xpub
    • outputs: Return transactions sending outputs to this xpub
    • =: Return specific numerical vout index
  • assetMask: What type of transactions to return (default all)
    • all: Returns all types of transactions, base and asset type. The assetMask will represent value of all values OR'ed together see below in = for the masks.
    • non-tokens: Return only base coin transactions no asset type. The assetMask will represent value of basecoin.
    • token-only: Return only asset type transactions no base coin type. The assetMask will represent value of assetactivate | assetupdate | assetsend | syscoinburntoallocation | assetallocationburntosyscoin | assetallocationburntoethereum | assetallocationmint | assetallocationsend.
    • token-transfers: Return only assetallocationsend type transactions. The assetMask will represent value of assetallocationsend.
    • non-token-transfers: Return any transactions not of type assetallocationsend. The assetMask will represent value of token-only &^ token-transfers
    • =: Apply a custom numerical mask which is a bitmask of the following values:
      • basecoin: 1
      • assetallocationsend: 2
      • syscoinburntoallocation: 4
      • assetallocationburntosyscoin: 8
      • assetallocationburntoethereum: 16
      • assetallocationmint: 32
      • assetupdate: 64
      • assetsend: 128
      • assetactivate: 256
  • contract: return only transactions which affect specified contract or asset (applicable only to Ethereum and Syscoin)

Response:

{
"page": 1,
"totalPages": 1,
"itemsOnPage": 1000,
"address": "dgub8sbe5Mi8LA4dXB9zPfLZW8arm...9Vjp2HHx91xdDEmWYpmD49fpoUYF",
"balance": "0",
"totalReceived": "3083381250",
"totalSent": "3083381250",
"unconfirmedBalance": "0",
"unconfirmedTxs": 0,
"txs": 5,
"txids": [
"383ccb5da16fccad294e24a2ef77bdee5810573bb1b252d8b2af4f0ac8c4e04c",
"75fb93d47969ac92112628e39148ad22323e96f0004c18f8c75938cffb6c1798",
"e8cd84f204b4a42b98e535e72f461dd9832aa081458720b0a38db5856a884876",
"57833d50969208091bd6c950599a1b5cf9d66d992ae8a8d3560fb943b98ebb23",
"9cfd6295f20e74ddca6dd816c8eb71a91e4da70fe396aca6f8ce09dc2947839f",
],
"usedTokens": 2,
"tokens": [
{
"type": "XPUBAddress",
"name": "DUCd1B3YBiXL5By15yXgSLZtEkvwsgEdqS",
"path": "m/44'/3'/0'/0/0",
"transfers": 3,
"decimals": 8,
"balance": "0",
"totalReceived": "2803986975",
"totalSent": "2803986975"
},
{
"type": "XPUBAddress",
"name": "DKu2a8Wo6zC2dmBBYXwUG3fxWDHbKnNiPj",
"path": "m/44'/3'/0'/1/0",
"transfers": 2,
"decimals": 8,
"balance": "0",
"totalReceived": "279394275",
"totalSent": "279394275"
}
]
}

Note: usedTokens always returns total number of used addresses of xpub.

Get utxo#

Returns array of unspent transaction outputs of address or xpub, applicable only for Bitcoin-type coins. By default, the list contains both confirmed and unconfirmed transactions. The query parameter confirmed=true disables return of unconfirmed transactions. The returned utxos are sorted by block height, newest blocks first. For xpubs the response also contains address and derivation path of the utxo.

Unconfirmed utxos do not have field height, the field confirmations has value 0 and may contain field lockTime, if not zero.

Coinbase utxos do have field coinbase set to true, however due to performance reasons only up to minimum coinbase confirmations limit (100). After this limit, utxos are not detected as coinbase.

GET /api/v2/utxo/<address|xpub>[?confirmed=true]

Response:

[
{
"txid": "13d26cd939bf5d155b1c60054e02d9c9b832a85e6ec4f2411be44b6b5a2842e9",
"vout": 0,
"value": "1422303206539",
"confirmations": 0,
"lockTime": 2648100
},
{
"txid": "a79e396a32e10856c97b95f43da7e9d2b9a11d446f7638dbd75e5e7603128cac",
"vout": 1,
"value": "39748685",
"height": 2648043,
"confirmations": 47,
"coinbase": true
},
{
"txid": "de4f379fdc3ea9be063e60340461a014f372a018d70c3db35701654e7066b3ef",
"vout": 0,
"value": "122492339065",
"height": 2646043,
"confirmations": 2047
},
{
"txid": "9e8eb9b3d2e8e4b5d6af4c43a9196dfc55a05945c8675904d8c61f404ea7b1e9",
"vout": 0,
"value": "142771322208",
"height": 2644885,
"confirmations": 3205
}
]

Get block#

Returns information about block with transactions, subject to paging.

GET /api/v2/block/<block height|block hash>

Response:

{
"page": 1,
"totalPages": 1,
"itemsOnPage": 1000,
"hash": "760f8ed32894ccce9c1ea11c8a019cadaa82bcb434b25c30102dd7e43f326217",
"previousBlockHash": "786a1f9f38493d32fd9f9c104d748490a070bc74a83809103bcadd93ae98288f",
"nextBlockHash": "151615691b209de41dda4798a07e62db8429488554077552ccb1c4f8c7e9f57a",
"height": 2648059,
"confirmations": 47,
"size": 951,
"time": 1553096617,
"version": 6422787,
"merkleRoot": "6783f6083788c4f69b8af23bd2e4a194cf36ac34d590dfd97e510fe7aebc72c8",
"nonce": "0",
"bits": "1a063f3b",
"difficulty": "2685605.260733312",
"txCount": 2,
"txs": [
{
"txid": "2b9fc57aaa8d01975631a703b0fc3f11d70671953fc769533b8078a04d029bf9",
"vin": [
{
"n": 0,
"value": "0"
}
],
"vout": [
{
"value": "1000100000000",
"n": 0,
"addresses": [
"D6ravJL6Fgxtgp8k2XZZt1QfUmwwGuLwQJ"
],
"isAddress": true
}
],
"blockHash": "760f8ed32894ccce9c1ea11c8a019cadaa82bcb434b25c30102dd7e43f326217",
"blockHeight": 2648059,
"confirmations": 47,
"blockTime": 1553096617,
"value": "1000100000000",
"valueIn": "0",
"fees": "0"
},
{
"txid": "d7ce10ecf9819801ecd6ee045cbb33436eef36a7db138206494bacedfd2832cf",
"vin": [
{
"n": 0,
"addresses": [
"9sLa1AKzjWuNTe1CkLh5GDYyRP9enb1Spp"
],
"isAddress": true,
"value": "1277595845202"
}
],
"vout": [
{
"value": "9900000000",
"n": 0,
"addresses": [
"DMnjrbcCEoeyvr7GEn8DS4ZXQjwq7E2zQU"
],
"isAddress": true
},
{
"value": "1267595845202",
"n": 1,
"spent": true,
"addresses": [
"9sLa1AKzjWuNTe1CkLh5GDYyRP9enb1Spp"
],
"isAddress": true
}
],
"blockHash": "760f8ed32894ccce9c1ea11c8a019cadaa82bcb434b25c30102dd7e43f326217",
"blockHeight": 2648059,
"confirmations": 47,
"blockTime": 1553096617,
"value": "1277495845202",
"valueIn": "1277595845202",
"fees": "100000000"
}
]
}

Note: Blockbook always follows the main chain of the backend it is attached to. If there is a rollback-reorg in the backend, Blockbook will also do rollback. When you ask for block by height, you will always get the main chain block. If you ask for block by hash, you may get the block from another fork but it is not guaranteed (backend may not keep it)

Send transaction#

Sends new transaction to backend.

GET /api/v2/sendtx/<hex tx data>
POST /api/v2/sendtx (hex tx data in request body)

Response:

{
"result": "7c3be24063f268aaa1ed81b64776798f56088757641a34fb156c4f51ed2e9d25"
}

or in case of error

{
"error": {
"message": "error message"
}
}

Tickers list#

Returns a list of available currency rate tickers for the specified date, along with an actual data timestamp.

GET /api/v2/tickers-list/?timestamp=<timestamp>

The query parameters:

  • timestamp: specifies a Unix timestamp to return available tickers for.

Example response:

{
"ts":1574346615,
"available_currencies": [
"eur",
"usd"
]
}

Tickers#

Returns currency rate for the specified currency and date. If the currency is not available for that specific timestamp, the next closest rate will be returned. All responses contain an actual rate timestamp.

GET /api/v2/tickers/[?currency=<currency>&timestamp=<timestamp>]

The optional query parameters:

  • currency: specifies a currency of returned rate ("usd", "eur", "eth"...). If not specified, all available currencies will be returned.
  • timestamp: a Unix timestamp that specifies a date to return currency rates for. If not specified, the last available rate will be returned.

Example response (no parameters):

{
"ts": 1574346615,
"rates": {
"eur": 7134.1,
"usd": 7914.5
}
}

Example response (currency=usd):

{
"ts": 1574346615,
"rates": {
"usd": 7914.5
}
}

Example error response (e.g. rate unavailable, incorrect currency...):

{
"ts":7980386400,
"rates": {
"usd": -1
}
}

Balance history#

Returns a balance history for the specified XPUB or address.

GET /api/v2/balancehistory/<XPUB | address>?from=<dateFrom>&to=<dateTo>[&fiatcurrency=<currency>&groupBy=<groupBySeconds>

Query parameters:

  • from: specifies a start date as a Unix timestamp
  • to: specifies an end date as a Unix timestamp

The optional query parameters:

  • fiatcurrency: if specified, the response will contain fiat rate at the time of transaction. If not, all available currencies will be returned.
  • groupBy: an interval in seconds, to group results by. Default is 3600 seconds.

Example response (fiatcurrency not specified):

[
{
"time": 1578391200,
"txs": 5,
"received": "5000000",
"sent": "0",
"rates": {
"usd": 7855.9,
"eur": 6838.13,
...
}
},
{
"time": 1578488400,
"txs": 1,
"received": "0",
"sent": "5000000",
"rates": {
"usd": 8283.11,
"eur": 7464.45,
...
}
}
]

Example response (fiatcurrency not specified):

[
{
"time": 1578391200,
"txs": 5,
"received": "5000000",
"sent": "0",
"sentToSelf":"100000",
"rates": {
"usd": 7855.9,
"eur": 6838.13,
...
}
},
{
"time": 1578488400,
"txs": 1,
"received": "0",
"sent": "5000000",
"sentToSelf":"0",
"rates": {
"usd": 8283.11,
"eur": 7464.45,
...
}
}
]

Example response (fiatcurrency=usd):

[
{
"time": 1578391200,
"txs": 5,
"received": "5000000",
"sent": "0",
"sentToSelf":"0",
"rates": {
"usd": 7855.9
}
},
{
"time": 1578488400,
"txs": 1,
"received": "0",
"sent": "5000000",
"sentToSelf":"0",
"rates": {
"usd": 8283.11
}
}
]

Example response (fiatcurrency=usd&groupBy=172800):

[
{
"time": 1578355200,
"txs": 6,
"received": "5000000",
"sent": "5000000",
"sentToSelf":"0",
"rates": {
"usd": 7734.45
}
}
]

The value of sentToSelf is the amount sent from the same address to the same address or within addresses of xpub.

Websocket API#

Websocket interface is provided at /websocket/. The interface can be explored using Blockbook Websocket Test Page found at /test-websocket.html.

The websocket interface provides the following requests:

  • getInfo
  • getBlockHash
  • getAccountInfo
  • getAccountUtxo
  • getTransaction
  • getTransactionSpecific
  • getBalanceHistory
  • getCurrentFiatRates
  • getFiatRatesTickersList
  • getFiatRatesForTimestamps
  • estimateFee
  • sendTransaction
  • ping

The client can subscribe to the following events:

  • subscribeNewBlock - new block added to blockchain
  • subscribeNewTransaction - new transaction added to blockchain (all addresses)
  • subscribeAddresses - new transaction for given address (list of addresses)
  • subscribeFiatRates - new currency rate ticker

There can be always only one subscription of given event per connection, i.e. new list of addresses replaces previous list of addresses.

The subscribeNewTransaction event is not enabled by default. To enable support, blockbook must be run with the -enablesubnewtx flag.

Note: If there is reorg on the backend (blockchain), you will get a new block hash with the same or even smaller height if the reorg is deeper

Websocket communication format

{
"id":"1", //an id to help to identify the response
"method":"<The method that you would like to call>",
"params":<The params (same as in the API call>
}

Example for subscribing to an address (or multiple addresses)

{
"id":"1",
"method":"subscribeAddresses",
"params":{
"addresses":["mnYYiDCb2JZXnqEeXta1nkt5oCVe2RVhJj", "tb1qp0we5epypgj4acd2c4au58045ruud2pd6heuee"]
}
}

Legacy API V1#

The legacy API is a compatible subset of API provided by Bitcore Insight. It supports only Bitcoin-type coins. The details of the REST/socket.io requests can be found in the Insight's documentation.

REST API#

GET /api/v1/block-index/<block height>
GET /api/v1/tx/<txid>
GET /api/v1/address/<address>
GET /api/v1/utxo/<address>
GET /api/v1/block/<block height | block hash>
GET /api/v1/estimatefee/<number of blocks>
GET /api/v1/sendtx/<hex tx data>
POST /api/v1/sendtx (hex tx data in request body)

Socket.io API#

Socket.io interface is provided at /socket.io/. The interface also can be explored using Blockbook Socket.io Test Page found at /test-socketio.html.

The legacy API is provided as is and will not be further developed.

The legacy API is currently (Blockbook v0.3.5) also accessible without the /v1/ prefix, however in the future versions the version less access will be removed.

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/examples/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/examples/index.html index 61abb125..a40234d3 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/examples/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/examples/index.html @@ -6,13 +6,13 @@ Examples | Syscoin Docs - +

Examples

Burn Asset to Ethereum#

Burn Asset to Syscoin#

Burn SYS to Asset#

Create Asset#

Issue Asset#

Issue NFT 1#

Issue NFT 2#

Mint Asset to Syscoin 1#

Mint Asset to Syscoin 2#

Send SYS#

Send SYS with Memo#

Transfer Asset#

Transfer Asset Funded by an Address#

Transfer Asset Funded by Multiple Signers#

Transfer Asset Funded by xPUB#

Transfer Asset with Memo#

Update Asset#

Update Asset AuxFees#

Update Asset Notary Details#

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/hdsigner/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/hdsigner/index.html index 532fa5de..bd041c8c 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/hdsigner/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/hdsigner/index.html @@ -6,13 +6,13 @@ HDSigner | Syscoin Docs - +

HDSigner

These are the HDSigner exported functions, the HDSigner is used to manage and sign transactions internally using your XPUB (HD wallets). BIP44/BIP84 are supported. P2WPKH, P2WSH, P2PKH, P2SH.

backup#

backup()#

Encrypt to password and backup to local storage for persistence.

createAccount#

createAccount()#

Create and derive a new account.

createKeypair#

createKeypair( addressIndex, isChange)#

Derives a bitcoinjs-lib key pair based on the address index and change marker provided.

deriveAccount#

deriveAccount( index )#

Derive a HD account based on the index number passed in.

deriveKeypair#

deriveKeypair( keypath )#

Takes an HD path and derives the key pair from it.

derivePubKey#

derivePubKey( keypath )#

Takes an HD path, derives a key pair from it and returns the public key.

getAccountXpub#

getAccountXpub()#

Gets the xPub for the account currently in use by the HDSigner, useful for public provider look-ups based on xPub accounts.

getAddressFromKeypair#

getAddressFromKeypair( keyPair )#

Takes a key pair and gives back a P2WPKH address.

getAddressFromPubKey#

getAddressFromPubKey( pubKey )#

Takes a public key and gives back a P2WPKH address.

getMasterFingerprint#

getMasterFingerprint()#

Get the master seed fingerprint used for signing bitcoinjs-lib PSBTs.

getNewChangeAddress#

getNewChangeAddress( skipIncrement )#

Get new address for sending change to.

getNewReceivingAddress#

getNewReceivingAddress( skipIncrement )#

Get new address for sending coins to.

getRootNode#

getRootNode()#

Returns the HDSigner's BIP32 root node.

restore#

restore( password )#

Restore on load from local storage and decrypt data to de-serialize objects.

setAccountIndex#

setAccountIndex( accountIndex )#

Set HD account based on accountIndex number passed in so HD indexes (change/receiving) will be updated accordingly to this account.

setLatestIndexesFromXPubTokens#

setLatestIndexesFromXPubTokens( tokens )#

Sets the change and receiving indexes from xPub tokens passed in, from a back-end provider response.

sign#

sign( res )#

Create signing information based on the HDSigner (if set)

signPSBT#

signPSBT( psbt, ownedIndexes )#

Signs a PSBT with xPub information from the HDSigner.

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/overview/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/overview/index.html index e61d3afd..6381e92c 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/overview/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/overview/index.html @@ -6,13 +6,13 @@ Overview | Syscoin Docs - +

Overview

This reference documentation is a community effort and is currently still a WIP, as such there will still be some information missing. Please let us know in the Discord if you find mistakes or things that should be added.

The diagram below shows the layout of the syscoinjs-lib module.

  • Syscoinjs-lib provides general functions for signing and sending transactions, as well as creating/issuing/sending tokens.
  • Utils.js provides utility functions that return information related to user accounts, addresses, tokens as well as many others.
  • HDSigner and TrezorSigner are used to sign transactions using software or using a Trezor hardware wallet respectively.

image-20211205153306662

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/syscoinjs/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/syscoinjs/index.html index 1fb21d54..f066032c 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/syscoinjs/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/syscoinjs/index.html @@ -6,13 +6,13 @@ Syscoinjs-lib | Syscoin Docs - +

Syscoinjs-lib

A Javascript library for utilising Syscoin blockchain operations in node.js and browsers.

This documentation is currently a WIP. Please let us know if you notice any typos or have any ideas for improvement.

assetAllocationBurn#

assetAllocationBurn( assetOpts, txOpts, assetMap, sysChangeAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Burn an asset allocation for the purpose of provably burning. Could be used to create proof-of-burn for SysNEVM bridge by specifying the NEVM address as the destination in assetOpts.

assetAllocationMint#

assetAllocationMint( assetOpts, txOpts, assetMap, sysChangeAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Mint a new asset using proof-of-lock on NEVM chain as a proof to mint tokens on Syscoin.

assetAllocationSend#

assetAllocationSend( txOpts, assetMap, sysChangeAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Send an asset allocation to other users. Once the assetSend() function has been used to issue a token to an address this function is then used to send the tokens.

assetNew#

assetNew( assetOpts, txOpts, sysChangeAddress, sysReceivingAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Create new Syscoin Platform Token (SPT).

assetSend#

assetSend( txOpts, assetMap, sysChangeAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Issue supply by sending it from asset to an address holding an allocation of the asset.

assetUpdate#

assetUpdate( assetGuid, assetOpts, txOpts, assetMap, sysChangeAddress, sysReceivingAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Update an existing Syscoin Platform Token (SPT).

createPSBTFromRes#

createPSBTFromRes( res, redeemOrWitnessScript )#

Crafts a PSBT from a res object. Detects witness/non-witness UTXOs and sets appropriate data required for bitcoinjs-lib to sign properly.

createTransaction#

createTransaction( txOpts, changeAddress, outputsArr, feeRate, fromXpubOrAddress, utxos, redeemOrWitnessScript )#

This function is used to send Syscoin or Bitcoin or like coins.

fetchAndSanitizeUTXOs#

fetchAndSanitizeUTXOs( utxos, fromXpubOrAddress, txOpts, assetMap, excludeZeroConf )#

Fetch UTXO's for an address or xPub from back-end Blockbook provider and sanitize them for use by upstream libraries.

signAndSend#

signAndSend( res, notaryAssets )#

Signs and Notarizes if necessary and sends a transaction to the network using Signer.

signAndSendWithSigner#

signAndSendWithSigner( res, Signer, notaryAssets )#

Signs and Notarizes if necessary and sends a transaction to the network using Signer.

signAndSendWithWIF#

signAndSendWithWIF( res, wif, notaryAssets )#

Signs and Notarizes if necessary and sends a transaction to the network using Signer.

Syscoin#

Syscoin( Signer, blockbookURL, network )#

Constructor.

Top level object used by consuming libraries to craft Syscoin/Bitcoin transactions. For Syscoin SPT support is provided.

syscoinBurnToAssetAllocation#

syscoinBurnToAssetAllocation( txOpts, assetMap, sysChangeAddress, feeRate, sysFromXpubOrAddress, utxos, redeemOrWitnessScript )#

Burn Syscoin to mint SYSX.

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/trezorsigner/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/trezorsigner/index.html index f97f3e86..0f91f839 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/trezorsigner/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/trezorsigner/index.html @@ -6,13 +6,13 @@ TrezorSigner | Syscoin Docs - +

TrezorSigner

These are the TrezorSigner exported functions, TrezorSigner is used to manage and sign transactions using a Trezor hardware wallet. BIP44/BIP84 are supported. P2WPKH, P2WSH, P2PKH, P2SH.

backup#

backup()#

Encrypt to password and backup to local storage for persistence.

convertToTrezorFormat#

convertToTrezorFormat()#

Converts a Syscoin PSBT to Trezor format.

createAccount#

createAccount()#

Create and derive a new account.

deriveAccount#

deriveAccount( index )#

Derive a HD account based on the index number passed in.

getAccountNode#

getAccountNode()#

Returns the TrezorSigner's BIP32 root node.

getAccountXpub#

getAccountXpub()#

Gets the xPub for the account currently in use by the TrezorSigner, useful for public provider look-ups based on xPub accounts.

getAddressFromPubKey#

getAddressFromPubKey( pubKey )#

Takes a public key and gives back a P2WPKH address.

getNewChangeAddress#

getNewChangeAddress( skipIncrement )#

Get new address for sending change to.

getNewReceivingAddress#

getNewReceivingAddress( skipIncrement )#

Get new address for sending coins to.

restore#

restore( password )#

Restore on load from local storage and decrypt data to de-serialize objects.

setAccountIndex#

setAccountIndex( accountIndex )#

Set HD account based on accountIndex number passed in so HD indexes (change/receiving) will be updated accordingly to this account.

setLatestIndexesFromXPubTokens#

setLatestIndexesFromXPubTokens( tokens )#

Sets the change and receiving indexes from xPub tokens passed in, from a back-end provider response.

sign#

sign( res )#

Create signing information based on the TrezorSigner (if set)

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/types/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/types/index.html index d710dc49..25951d3a 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/types/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/types/index.html @@ -6,13 +6,13 @@ Types | Syscoin Docs - +

Types

Allocation#

AssetDetails#

AssetIDs#

AssetInfo#

AssetOptions#

AssetOutput#

AssetOutputs#

AuxFee#

AuxFeeDetails#

BIP32Node#

KeyPair#

Network#

Networks#

NotaryDetails#

Output#

PSBT#

PSBTInput#

Res#

ResInput#

SanitizedAssetDetails#

SanitizedUTXO#

SanitizedUTXOs#

SPSBT#

SpvProof#

Transaction#

TransactionOptions#

TrezorTransaction#

UnknownKeyValue#

UpdateCapabilityFlags#

Used to define what details of a token/asset can be updated. This is a bitmask value, so the final value should be all of the flags you would like to set added together. For example, if you wanted the ability to update the notary address (8) and notary details (16) only, your value would be 24.

UTXO#

UTXOs#

WitnessUTXO#

- + \ No newline at end of file diff --git a/docs/dev-resources/documentation/javascript-sdk-ref/utils/index.html b/docs/dev-resources/documentation/javascript-sdk-ref/utils/index.html index 3231e48e..7af33c3b 100644 --- a/docs/dev-resources/documentation/javascript-sdk-ref/utils/index.html +++ b/docs/dev-resources/documentation/javascript-sdk-ref/utils/index.html @@ -6,13 +6,13 @@ Utils | Syscoin Docs - +

Utils

These are the utility functions found in utils.js.

buildEthProof#

buildEthProof( assetInfo )#

Build Ethereum SPV proof using eth-proof library.

createAssetID#

createAssetID( NFTID, assetGuid )#

Returns the GUID for a child asset with the given NFT ID, which would be issued from the specified base asset.

fetchBackendAccount#

fetchBackendAccount( backendURL, addressOrXpub, options, xpub, signer )#

Fetch address or xPub information including transactions and balance information (based on options) from backend Blockbook provider.

fetchBackendAsset#

fetchBackendAsset( backendURL, assetGuid )#

Fetches asset information from the backend Blockbook provider for a specific token/asset, given by the GUID.

fetchBackendBlock#

fetchBackendBlock( backendURL, blockhash )#

Fetches the information for a block from the backend, specified by the block hash.

fetchBackendListAssets#

fetchBackendListAssets( backendUrl, filter )#

Fetches a list of assets from backend Blockbook provider via a filter

fetchBackendRawTx#

fetchBackendRawTx( backendURL, txid )#

Fetches the information for a transaction from the backend, specified by the transaction ID (txid).

fetchBackendSPVProof#

fetchBackendSPVProof( backendURL, txid )#

Fetches a SPV Proof from the backend Blockbook provider. To be used to create a proof for the NEVM bridge.

fetchBackendUTXOS#

fetchBackendUTXOS( backendURL, addressOrXpub, options )#

Fetch the UTXOs for an address or XPUB from the backend Blockbook provider.

fetchEstimateFee#

fetchEstimateFee( backendURL, blocks, options )#

Get estimated fee from backend.

fetchNotarizationFromEndPoint#

fetchNotarizationFromEndPoint( endPoint, txHex )#

Fetch notarization signature via axois from an endPoint URL, see spec for more info: https://github.com/syscoin/sips/blob/master/sip-0002.mediawiki

fetchProviderInfo#

fetchProviderInfo( backendURL )#

Fetches the provider info including blockbook and backend data.

getAllocationsFromTx#

getAllocationsFromTx( tx )#

Get allocation information for an asset transaction.

getAssetsRequiringNotarization#

getAssetsRequiringNotarization( res, assets )#

Get assets from the Result object assigned from syscointx.createTransaction() / syscointx.createAssetTransaction() that require notarization.

getAssetIDs#

getAssetIDs( assetGuid )#

Given a certain child asset's GUID this will return the base asset's GUID as well as the child asset's NFT ID.

getBaseAssetID#

getBaseAssetID( assetGuid )#

Given a certain child asset's GUID this will return the base asset's GUID, from which the child was issued with a NFT ID.

getMemoFromOpReturn#

getMemoFromOpReturn( outputs, memoHeader )#

Returns the memo from an array of outputs by finding the OP_RETURN output and extracting the memo from the script, returns null if not found.

getMemoFromScript#

getMemoFromScript( script, memoHeader )#

Get the memo from a script.

getNotarizationSignatures#

getNotarizationSignatures( notaryAssets, txHex )#

Get notarization signatures from a notary endpoint defined in the asset object. See spec for more info.

HDSigner#

HDSigner( mnemonic, password, isTestnet, networks, SLIP44, pubTypes )#

Manage an HD wallet and accounts, connects to SyscoinJS object.

notarizePSBT#

notarizePSBT( psbt, notaryAssets, rawTx )#

Notarize Result object from syscointx.createTransaction() / syscointx.createAssetTransaction() if required by the assets in the inputs of the transaction

sanitizeBlockbookUTXOs#

sanitizeBlockbookUTXOs( sysFromXpubOrAddress, utxoObj, network, txOpts, assetMap, excludeZeroConf )#

Sanitize back-end provider UTXO objects to be useful for this library.

sendRawTransaction#

sendRawTransaction( backendURL, txHex, signer )#

Sends a raw transaction to the backend Blockbook provider to send to the network.

setTransactionMemo#

setTransactionMemo( rawHex, memoHeader, buffMemo )#

Sets a transaction's memo, or returns null if not found.

signWithWIF#

signWithWIF( psbt, wif, network )#

Signs a PSBT/Result object with a WIF

TrezorSigner#

TrezorSigner( password, isTestnet, networks, SLIP44, pubTypes, connectSrc, disableLazyLoad )#

Manage an HD wallet and accounts using a Trezor hardware wallet.

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/communities/index.html b/docs/dev-resources/nevm/communities/index.html index db4521ad..209f4a9e 100644 --- a/docs/dev-resources/nevm/communities/index.html +++ b/docs/dev-resources/nevm/communities/index.html @@ -6,13 +6,13 @@ Communities | Syscoin Docs - +

Communities

These are a few of the Web3 and cryptocurrency development communities that you should be a part of to further your knowledge and understanding of the present and future of blockchain technology, and connect with like-minded developers.

CryptoDevs Discord

This is a Discord server that is centred around blockchain development and is a great place to find like-minded developers who are also interested in developing for or learning about blockchain and dApp development. Join the server here.

ZK-Rollup-related Discords

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/docs-and-libs/index.html b/docs/dev-resources/nevm/docs-and-libs/index.html index 0de9b09a..bec867ab 100644 --- a/docs/dev-resources/nevm/docs-and-libs/index.html +++ b/docs/dev-resources/nevm/docs-and-libs/index.html @@ -6,13 +6,13 @@ Documentation & Libraries | Syscoin Docs - +

Documentation & Libraries

These are the main libraries that are used in the creation of smart contracts and dApps. Gaining knowledge and experience with these will future-proof your smart contract and Web3 abilities. For tutorials on how to use these in practice, check here.

Solidity Documentation

Solidity is the programming language used to write smart contracts on EVM-based blockchains.

Web3.js Documentation

Web3.js is one of the foremost Javascript libraries used for creating browser dApps for EVM-compatible chains.

Ethers.js Documentation

Ethers.js is a Javascript library that is similar to Web3.js that has gained a lot of popularity with dApp developers.

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/guides-and-tuts/index.html b/docs/dev-resources/nevm/guides-and-tuts/index.html index 6bc6f378..9879e1dd 100644 --- a/docs/dev-resources/nevm/guides-and-tuts/index.html +++ b/docs/dev-resources/nevm/guides-and-tuts/index.html @@ -6,13 +6,13 @@ Courses, Guides & Tutorials | Syscoin Docs - +

Courses, Guides & Tutorials

Below are some courses, guides and tutorials that will either give you a simple and gentle introduction to getting started with the tooling for creating and deploying smart contracts, or they will take you on the full journey towards dApp development.

CryptoZombies

The most popular course for how to create smart contracts, CryptoZombies has taught over 415,672 students how to code in Solidity and create dApps.

Create and Deploy Smart Contracts using Remix

Follow the guide here. To change your network to NEVM in MetaMask follow the guide here.

Create and Deploy Smart Contracts using Truffle

Follow the guide here.

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/resources/index.html b/docs/dev-resources/nevm/resources/index.html index 5c323e28..223f70e0 100644 --- a/docs/dev-resources/nevm/resources/index.html +++ b/docs/dev-resources/nevm/resources/index.html @@ -6,13 +6,13 @@ Resources | Syscoin Docs - +

Resources

This page contains resources that will help facilitate developers building on Syscoin's NEVM. As it is forked from Ethereum the development process is essentially the same for writing, deploying and testing smart contracts and utilizing them through dApps. As such the following resources will not be an exhaustive list but will be a list of resources that are some of the favorites used by solidity smart contract/dApp developers.

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/tooling/index.html b/docs/dev-resources/nevm/tooling/index.html index 65c35027..f58ba18b 100644 --- a/docs/dev-resources/nevm/tooling/index.html +++ b/docs/dev-resources/nevm/tooling/index.html @@ -6,13 +6,13 @@ Tooling | Syscoin Docs - +

Tooling

Below are a list of tools that will be greatly beneficial to you when you're designing and creating the next big dApp!

Truffle Suite:

  • Truffle - A world class development environment, testing framework and asset pipeline for blockchains using the Ethereum Virtual Machine (EVM), aiming to make life as a developer easier.
  • Ganache - A personal blockchain for Ethereum development you can use to deploy contracts, develop your applications, and run tests. It is available as both a desktop application as well as a command-line tool (formerly known as the TestRPC). Ganache is available for Windows, Mac, and Linux.
  • Drizzle - A collection of front-end libraries that make writing dapp front-ends easier and more predictable. The core of Drizzle is based on a Redux store, so you have access to the spectacular development tools around Redux. We take care of synchronizing your contract data, transaction data and more.

Hardhat

Hardhat is a more recently released development environment that has similarities to Truffle, it provides the ability to compile, deploy, test and debug solidity smart contracts.

Remix IDE

Remix is an in-browser IDE that enables the writing, deploying and testing of smart contracts. It gives developers the ability to connect to any network they like through the use of browser extensions like MetaMask.

Syscoin RPC Providers

  • Syscoin Foundation provides mainnet and testnet shared nodes for RPC.
  • Getblock provides mainnet shared nodes for RPC and the option of dedicated nodes.
  • Ankr provides mainnet shared nodes for RPC and the option of dedicated nodes.

- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/truffle/index.html b/docs/dev-resources/nevm/truffle/index.html index e6541240..e1793540 100644 --- a/docs/dev-resources/nevm/truffle/index.html +++ b/docs/dev-resources/nevm/truffle/index.html @@ -6,7 +6,7 @@ Deploying Smart Contracts with Truffle | Syscoin Docs - + @@ -32,7 +32,7 @@
Summary
=======
> Total deployments: 2
> Final cost: 0.000963052502696547 ETH

Congratulations! Your contracts have been deployed and in the Deploying 'HelloNEVM' section you can see the contract's address, which is worth saving if you wish to interact with it at a later date.

5. Interact with the smart contract#

cd to the root of your project directory then use this command to use Truffle on the Tanenbaum network (as specified in the truffle-config.js)

truffle console --network tanenbaum

You can then call the sayHello() function with the following input:

HelloNEVM.deployed().then(function(instance){return instance.sayHello()});
- + \ No newline at end of file diff --git a/docs/dev-resources/nevm/zk-rollups/index.html b/docs/dev-resources/nevm/zk-rollups/index.html index d0229d67..637daa29 100644 --- a/docs/dev-resources/nevm/zk-rollups/index.html +++ b/docs/dev-resources/nevm/zk-rollups/index.html @@ -6,13 +6,13 @@ Rollups | Syscoin Docs - +

Rollups

Syscoin is focused on end-user adoption of its Rollux suite with Rollup technologies that serve as Layer 2, and using the Syscoin blockchain as the settlement layer for them.

Check out The Ultimate Guide to Rollups for an technical overview of rollups the differences between Optimistic and ZK rollups.

Syscoin Rollux#


Here are some different Rollup communities in the industry.

Optimistic Rollups#

  • Arbitrum - Offchain Labs are the builders of the Arbitrum solution and Nitro
  • Metis - Layer 2 solutions by MetisDAO
  • Optimism - Code base of Rollux OPv1, and creators of Bedrock

ZK-Rollups#

  • StarkWare - a layer 2 network that uses zkSTARK proofs and the Cairo programming language.
    • You can find a large number of StarkNet (StarkWare's main ZK-Rollup solution) resources here.
  • zkSync - an open-source scaling and privacy engine, which uses zkSNARK proofs.
  • Aztec - an open-source, layer 2 network that utilizes zkSNARK proofs, PLONK technology and the Noir programming language. Aztec is largely focused on private payments solutions.
- + \ No newline at end of file diff --git a/docs/dev-resources/sys/asset-index/index.html b/docs/dev-resources/sys/asset-index/index.html index 0ad9a2a8..eefaf055 100644 --- a/docs/dev-resources/sys/asset-index/index.html +++ b/docs/dev-resources/sys/asset-index/index.html @@ -6,7 +6,7 @@ SPT Asset Index Technical Description | Syscoin Docs - + @@ -32,7 +32,7 @@
Return JSON of all assets found to caller;

Q&A

What does re-org protected mean? It means that if the blockchain tip is disconnected for whatever reason (longer chain is found) then you have to rollback transactions, we wouldn't want our asset view to incorrectly show transactions as confirmed when they have been rolled back.

What does asset indexing mean? It means that we need a way to show all transactions related to an asset+address tuple. You need to be able to as a wallet or explorer view pertaining transactions for your asset allocation as a sender or receiver.

- + \ No newline at end of file diff --git a/docs/dev-resources/sys/exchange-integration/index.html b/docs/dev-resources/sys/exchange-integration/index.html index 027e579c..8e129ef5 100644 --- a/docs/dev-resources/sys/exchange-integration/index.html +++ b/docs/dev-resources/sys/exchange-integration/index.html @@ -6,7 +6,7 @@ SPT Exchange Integration | Syscoin Docs - + @@ -23,7 +23,7 @@ listtransactions is general purpose. It covers all transaction types and its output is verbose. listunspentasset <assetGuid> <minimum#ofConfirmations (optional)> is more specific.

$ syscoin-cli listunspentasset 530240372620954 10
[
{
"txid": "ac74df7b065bf501db991153920db3462780c8d238ef6fc5562ee7e4b2db565d",
"vout": 0,
"address": "tsys1qqzrxzg8cmyrl8xss353zkvty5qwlfga4r9tq4r",
"label": "Another address",
"scriptPubKey": "001400866120f8d907f39a108d222b3164a01df4a3b5",
"amount": 0.00500000,
"asset_guid": "530240372620954",
"asset_amount": 0.00000200,
"confirmations": 9771,
"spendable": true,
"solvable": true,
"desc": "wpkh([1712892e/0'/0'/1']02aec158d644eb2744479c7a0410e30b91d6278a1091ff7a4cd7caf6c132b1b820)#u0azeyff",
"safe": true
}
]

Get transaction details

$ syscoin-cli gettransaction fa4ee19861d5f9c0aa46d20f332458e559921255cf98c0873afc2462849588ba

Setup for using Blockbook API and syscoinjs-lib#

Syscoin Blockbook uses its own syscoind instance as the backend, and indexes the blockchain data and tracks XPUB-based account balances to serve the API.

Please follow the readme in https://www.github.com/syscoin/blockbook if you want to implement your own Blockbook server instance. syscoinjs-lib is used to communicate with blockbook server and the documentation is located at https://www.github.com/syscoin/syscoinjs-lib

Examples for using syscoinjs-lib are located at https://www.github.com/syscoin/syscoinjs-lib-examples

A public Blockbook server instance for Syscoin is located at https://sys1.bcfn.ca

- + \ No newline at end of file diff --git a/docs/dev-resources/sys/testnet/index.html b/docs/dev-resources/sys/testnet/index.html index dc680c2c..49162eda 100644 --- a/docs/dev-resources/sys/testnet/index.html +++ b/docs/dev-resources/sys/testnet/index.html @@ -6,13 +6,13 @@ Testnet Setup | Syscoin Docs - +

Testnet Setup

Syscoin 4.3 Testnet Setup Guide#

Below are the minimum requirements for your VPS. Please do not try to compile without the minimum.#

  • 64-bit CPU — 2 Cores (4 preferred)

  • 4gb RAM (real) minimum (8gb RAM preferred)

  • 4gb swap (if less than 8gb real RAM) Will need to use SSD if using Swap

  • KVM or OpenVZ (KVM preferred)

  • Linux OS — Minimum Ubuntu 18.04, LTS Ubuntu 20.04 LTS (Focal Fossa) preferred.

  • 80gb Disk Space (100gb+ SSD preferred).

  • Port open for Syscoin (default: 18369) and Geth (default: 30303)

Setup QT for Testnet#

You will need to setup a separate datadir for use on Testnet.

Replace 4.2 with 4.3 if necessary

Choose a location for the Testnet data and create a folder, I use

D:\Users\john\AppData\Roaming\Syscoin4.3TestNet

Open this folder and create a syscoin.conf file with the following and save it as syscoin.conf.

#rpc config
testnet=1
[test]
zmqpubnevm=
rpcuser=user
rpcpassword=password
listen=1
daemon=1
server=1
assetindex=1
port=18369
rpcport=18370
rpcallowip=127.0.0.1
gethtestnet=1
addnode=54.203.169.179
addnode=54.190.239.153

Close and save this file as syscoin.conf before running QT.

Now we need to tell QT to use this directory for Testnet

Use latest RC release and for windows use the win64.zip unzip and run from the download folder. (If you use the installer it will overwrite any existing installation)

https://github.com/syscoin/syscoin/releases

Locate your syscoin-qt.exe, Use 4.3rc x

Right click on it and create a shortcut

img

You might have to save it to your desktop

Rename the shortcut to something like

syscoin-qt.exe — TestNet

Right click on the shortcut and choose properties

In the target field add -datadir and the location (created above)after syscoin-qt.exe so it looks like this (note the space before -datadir)

“C:\Program Files\Syscoin\syscoin-qt.exe”
-datadir=D:\Users\john\AppData\Roaming\Syscoin4.3TestNet

img

If you want you can change the icon to distinguish it from Live

img

Press OK to save changes

Now run QT from this shortcut and it will run QT on Testnet

img

Once synced you can follow this guide to request tSYS for testing:

TSYS Faucets

You can also follow the testnet Sentry Node setup guide here:

Testnet Sentry Node Setup Guide

- + \ No newline at end of file diff --git a/docs/dev-resources/sys/testnet_sentrynode/index.html b/docs/dev-resources/sys/testnet_sentrynode/index.html index f77a8191..8bb59e81 100644 --- a/docs/dev-resources/sys/testnet_sentrynode/index.html +++ b/docs/dev-resources/sys/testnet_sentrynode/index.html @@ -6,13 +6,13 @@ Testnet Sentry Node Setup Guide | Syscoin Docs - +

Testnet Sentry Node Setup Guide

Please enable coin control and show Sentry Node tab from the options.

Note: If using an Operator to host your node you now need to follow their instructions. The following applies to self hosted nodes.#

SET UP VPS#

Log onto your Server using Putty as Root.#

**All text in boxes are commands and need to be typed (Copy/Paste into Putty followed by Enter.**

Install Nano (Text editor)

sudo apt-get update
sudo apt-get install nano

Manual Install

Open ports/enable firewalls etc.apt install ufw python virtualenv git unzip pv -y
ufw allow ssh/tcp
ufw limit ssh/tcp
ufw allow 18369/tcp
ufw allow 30303/tcp
ufw logging on
ufw enable

Install Swap file if you have only 4gb Memory

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
nano /etc/fstab

Add the following line at the end of the file, then press Ctrl + X to close the editor, then Y and Enter save the file.

/swapfile none swap sw 0 0

Install Syscoin Binaries :

wget https://github.com/syscoin/syscoin/releases/download/v4.3.0rc2/syscoin-4.3.0rc2-x86_64-linux-gnu.tar.gz
tar xf syscoin-4.3.0rc2-x86_64-linux-gnu.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin syscoin-4.3.0rc2/bin/*
rm -r syscoin-4.3.0rc2
mkdir ~/.syscoin

We need to create the config file

nano ~/.syscoin/syscoin.conf

Paste in the following:

testnet=1
[test]
rpcuser=user
rpcpassword=password
listen=1
daemon=1
server=1
assetindex=1
port=18369
rpcport=18370
rpcallowip=127.0.0.1
addnode=54.190.239.153
addnode=52.40.171.92

Press Ctrl + X to close the editor and Y and Enter save the file

Run Syscoin Core

syscoind

Check Blocks#

syscoin-cli getblockchaininfo

Install Sentinel

sudo apt-get update
sudo apt-get -y install git python3 virtualenv ## note this says python3
git clone https://github.com/syscoin/sentinel.git
cd sentinel
git checkout dev-4.x
virtualenv -p $(which python3) ./venv
./venv/bin/pip install -r requirements.txt

We now need to edit the sentinel config file

nano sentinel.conf
  1. If there is a # In front of syscoin_conf= then remove it and change it to syscoin_conf=/root/.syscoin/syscoin.conf
  2. Put a # next to network=mainnet and remove the # next to network=testnet to enable testnet version of sentinel.

Save

Should look like this

img

Finish Sentinel setup

Create a crontab entry to wake sentinel every 5 minutes.

crontab -e

Please wait and select Nano as the option if this is the first time you have done this and add this line to the end of the file, including * * * * *

* * * * * cd /root/sentinel && ./venv/bin/python bin/sentinel.py 2>&1 >> sentinel-cron.log

To Start Syscoind automatically on boot you can add this line.

//Thanks to Locutus

@reboot /usr/local/bin/syscoind -daemon >/dev/null 2>&1

Save

SETUP THE SENTRY NODE.

Return to QT

Note if using an existing address with seniority you will have to manually ‘lock’ the collateral until after you have registered the MN.#

Note the masternode.config file is no longer used.

More than one Sentry Node can not share the same collateral address, ownerKeyAddress or votingKeyAddress and payout address cannot be the same as owner or voting addresses.

Create a new address for collateral this does not need to be a legacy address anymore, or use an existing seniority address. This address can also be in an offline wallet that has signing capabilities.

getnewaddress mn1

Send exactly 100,000 tsys to this address

Identify the funding transaction#

Click Window> Console and enter the following command:

Note some commands now require an underscore

masternode_outputs

This should return a string of characters similar to the following:

{
"3304a4920f20e1e5cd1f34e5396556ded1e603296f7c5dd66c7ec4fe63cb008d": "0"
}

The first long string is your collateralHash, while the last number is the collateralIndex.

Generate a BLS key pair#

A public/secret BLS key pair is required to operate a Sentry Node. The secret key is specified on the Sentry Node itself, and allows it to be included in the deterministic Sentry Node list once a provider registration transaction with the corresponding public key has been created.

If you are using a hosting service, they may provide you with their public key, and you can skip this step. If you are hosting your own masternode or have agreed to provide your host with the BLS secret key, generate a BLS public/secret keypair in the Console and entering the following command:

bls_generate{
"secret": "1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7",
"public": "05afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de"
}

These keys are NOT stored by the wallet and must be kept secure, similar to the value provided in the past by the masternode genkey command.

Add the secret key to your Sentry Node configuration#

The public key will be used in following steps. The secret key must be entered in the syscoin.conf file on the Sentry Node. This allows the Sentry Node to watch the blockchain for relevant Pro*Tx transactions, and will cause it to start serving as a Sentry Node when the signed ProRegTx is broadcast by the owner (final step below). Log in to your Sentry Node using ssh or PuTTY and edit the configuration file as follows:

nano ~/.syscoin/syscoin.conf

The editor appears with the existing configuration. Add this line in the file, replacing the key with your BLS secret key generated above (excluding “ ”) and also add your VPS external address

masternodeblsprivkey=1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7
externalip=123.123.123.123

Press enter to make sure there is a blank line at the end of the file, then press Ctrl + X to close the editor and Y and Enter save the file. Note that providing a masternodeblsprivkey enables Sentry Node mode, which will automatically force the txindex=1, peerbloomfilters=1, and prune=0 settings necessary to provide Sentry Node service. We now need to restart the Sentry Node for this change to take effect. Enter the following commands, waiting a few seconds in between to give Syscoin time to shut down making sure you are in the root directory:

syscoin-cli stop
sleep 5
syscoind

We will now prepare the transaction used to register the Sentry Node on the network.

Prepare a ProRegTx transaction#

A pair of BLS keys for the operator were already generated above, and the secret key was entered on the Sentry Node. The public key is used in this transaction as the operatorPubKey.

First, we need to get a new, unused address from the wallet to serve as the owner key address (ownerKeyAddr). This is not the same as the collateral address holding 100000 Sys. This address must be different for each MN. Generate a new address as follows:

getnewaddress mn1-ownertsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0

This address can also be used as the voting key address (votingKeyAddr). Alternatively, you can specify an address provided to you by your chosen voting delegate, or simply generate a new voting key address as follows:

getnewaddress mn1-votingtsys1q9aejtrvkrlnqsfeqanr5zhrttg8g8g

Then either generate or choose an existing address to receive the owner’s Sentry Node payouts (payoutAddress). This address cannot be the same as your owner or voting address, it is also possible to use an address external to the wallet:

getnewaddress payoutstsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67

You can also optionally generate and fund another address as the transaction fee source (feeSourceAddress). If you selected an external payout address, you must specify a fee source address.

Either the payout address or fee source address must have enough balance to pay the transaction fee, or the register_prepare transaction will fail.

The private keys to the owner and fee source addresses must exist in the wallet submitting the transaction to the network. If your wallet is protected by a password, it must now be unlocked to perform the following commands. Unlock your wallet for 5 minutes:

walletpassphrase yourSecretPassword 300

To see a list of common errors for the registration process click https://bittyjohn1954.medium.com/syscoin-4-2-masternode-error-codes-df0b80828f5f

You can use the registration helper blow but will need tto edit the first command generate to change the port to 18369

Sysnode.info provides Sentry Node Operators with information and tools, including tools that make it easier to participate in governance.

Manually

We will now prepare an unsigned ProRegTx special transaction using the protx_register_prepare command. This command has the following syntax:

protx_register_prepare collateralHash collateralIndex ipAndPort ownerKeyAddr
operatorPubKey votingKeyAddr operatorReward payoutAddress (feeSourceAddress)

Open a text editor such as notepad ++to prepare this command. Replace each argument to the command as follows:

  • collateralHash: The txid of the 100000 Syscoin collateral funding transaction
  • collateralIndex: The output index of the 100000 Syscoin funding transaction
  • ipAndPort: Sentry Node IP address and port, in the format x.x.x.x:yyyy
  • ownerKeyAddr: The Syscoin address generated above for the owner address
  • operatorPubKey: The BLS public key generated above (or provided by your hosting service)
  • votingKeyAddr: The Syscoin address generated above, or the address of a delegate, used for proposal voting
  • operatorReward: The percentage of the block reward allocated to the operator as payment, 0 for no reward.
  • payoutAddress: A Syscoin address to receive the owner’s Sentry Node rewards
  • feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified.

Note that the operator is responsible for specifying their own reward address in a separate update_service transaction if you specify a non-zero operatorReward. The owner of the Sentry Node collateral does not specify the operator’s payout address.

Either the feeSourceAddress or payoutAddress must hold a small balance since a standard transaction fee is involved.

Example (remove line breaks if copying):

Note in this example I will use the same address for owner and voting and i will have sent a small amount of tSys to the payoutAddress for fees as i am not using feeSourceAddress.(Remember to lock your collateral if using a seniority address)protx_register_prepare
3304a4920f20e1e5cd1f4e5396556ded1e603296f7c5dd66c7ec4fe63cb008d
0
161.97.140.65:18369
tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0
05afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de
tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0
0
tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67

Output:

{
"tx": "5000000000010163dc2d9a36a7a620386a23002ab6b8a2aba0956e7e047b73a6cf27d9d51571e80100000000feffffff020000000000000000d16a4cce0100000000008d00cb63fec47e6cd65d7c6f2903e6d1de566539e5341fcde5e1200f92a404330000000000000000000000000000ffffa1618f4447c12f73258d961fe6082720ecc7415d4ebebdadb37905afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de2f73258d961fe6082720ecc7415d4ebebdadb3790000160014e7395ee2f4986418b03bee442c2f051c6357d0318e95079d496ed43baba5101dab0ab5ace776ac1b0b7fcba7711a2504c9ea36610074c89a3b00000000160014279a7a94c83130b3eee07f2c66b2faa94b6cfe990247304402201f1e01ab33d4f388386ca5df94818674cf4b1909806c3a92ffc11ded88d84dfb02206d289cca1fbd19bc5154c85ec4f1eb3748f77071d863ae4f6aa18f56807f76e801210298a88bd8293e4d0248eb89f276cb54c26b3686ea4e17df155a22bfed2426862800000000",
"collateralAddress": "TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG",
"signMessage": "tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0"
}

Next we will use the collateralAddress and signMessage fields to sign the transaction, and the output of the tx field to submit the transaction.

Sign the ProRegTx transaction#

We will now sign the content of the signMessage (returned above) field using the public key for the collateral address as specified in collateralAddress. The wallet used to sign must hold the private key to the collateral address and note that no internet connection is required for this step, meaning that the wallet can remain disconnected from the internet in cold storage to sign the message. The command takes the following syntax:

signmessagebech32 collateralAddress signMessage

Example: (excluding “ ”)

signmessagebech32 TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0

Output:

IGj1ORdk3yv/uAMKG+DZrBA/GTHX4dW8zn/rmMfGzOzCIaxqmyUbNveYtnqh9wLVECENMjyuyeR2VmB3ccNlRLw=

Submit the signed message#

We will now submit the ProRegTx special transaction to the blockchain to register the Sentry Node. This command must be sent from the wallet holding a balance on either the feeSourceAddress or payoutAddress, since a standard transaction fee is involved. The command takes the following syntax:

protx_register_submit tx sig

Where:

  • tx: The serialized transaction previously returned in the tx output field from the protx_register_prepare command
  • sig: The message returned from the signmessagebech32 command

Example: (excluding “ ”)

protx_register_submit 5000000000010163dc2d9a36a7a620386a23002ab6b8a2aba0956e7e047b73a6cf27d9d51571e80100000000feffffff020000000000000000d16a4cce0100000000008d00cb63fec47e6cd65d7c6f2903e6d1de566539e5341fcde5e1200f92a404330000000000000000000000000000ffffa1618f4447c12f73258d961fe6082720ecc7415d4ebebdadb37905afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de2f73258d961fe6082720ecc7415d4ebebdadb3790000160014e7395ee2f4986418b03bee442c2f051c6357d0318e95079d496ed43baba5101dab0ab5ace776ac1b0b7fcba7711a2504c9ea36610074c89a3b00000000160014279a7a94c83130b3eee07f2c66b2faa94b6cfe990247304402201f1e01ab33d4f388386ca5df94818674cf4b1909806c3a92ffc11ded88d84dfb02206d289cca1fbd19bc5154c85ec4f1eb3748f77071d863ae4f6aa18f56807f76e801210298a88bd8293e4d0248eb89f276cb54c26b3686ea4e17df155a22bfed2426862800000000 IGj1ORdk3yv/uAMKG+DZrBA/GTHX4dW8zn/rmMfGzOzCIaxqmyUbNveYtnqh9wLVECENMjyuyeR2VmB3ccNlRLw=

Output:

285fba6277586401f8efaf55d4eef7acfa6d690a30c0db7f213a0bb2c6194bd1

Your Sentry Node is now registered and will appear on the Deterministic Sentry Node List after the transaction is mined to a block. You can view this list on the Masternodes tab in QT, or in the console using the command protx_list valid, where the txid of the final protx_register_submit transaction identifies your Sentry Node.

At this point you can go back to your terminal window and monitor your Sentry Node by entering

syscoin-cli masternode_status

img

This information can also be seen by double clicking your Sentry Node in QT

Congratulations! Your Sentry Node is now running.

- + \ No newline at end of file diff --git a/docs/dev-resources/sys/z-dag/index.html b/docs/dev-resources/sys/z-dag/index.html index 50c5c804..7533f55e 100644 --- a/docs/dev-resources/sys/z-dag/index.html +++ b/docs/dev-resources/sys/z-dag/index.html @@ -6,13 +6,13 @@ Z-DAG Developer Guide | Syscoin Docs - +

Z-DAG Developer Guide

Z-DAG is a patent-pending transaction technology implemented on the Syscoin blockchain that enables near-instant, low-cost transactions that are highly scalable. Z-DAGs transactional throughput has been audited by third party blockchain auditing firm Whiteblock, you can view their report here. For more technical information on Z-DAG refer to the Z-DAG Syscoin Community page or the Syscoin Z-DAG Whitepaper.

Z-DAG Basics#

Z-DAG is an interactive protocol, meaning you can continue to check the Z-DAG status all the way up to the point of blockchain confirmation. In today's network conditions a minimum Z-DAG threshold of 10 seconds or later are typically secure (99.9999%). Within certain enterprise deployments lower Z-DAG thresholds can be considered secure dependent on network conditions.

A typical transaction workflow has 2 stages:

  1. The transaction enters the mempool (unconfirmed).
  2. The transaction is mined into a block (confirmed).

When using Z-DAG, there are 3 stages:

  1. The transaction enters the mempool (unconfirmed).
  2. After a predefined Z-DAG threshold time the interactive protocol is called and returns a Z-DAG status.
  3. The transaction is mined into a block (confirmed).

When step 2 returns a Z-DAG status of 0 (after the Z-DAG threshold) that means the SPT can be re-spent without the risk of double-spends. Longer Z-DAG thresholds provide a higher level of security. When transactions are in a Z-DAG state available balance for re-spending should be determined using the Z-DAG balance.

Understanding Z-DAG Statuses#

Z-DAG status is retrieved by the command assetallocationverifyzdag. The output will reflect one of the following status levels:

StatusDescription
-1NOT FOUND (transaction is already confirmed on-chain, or is not a Z-DAG transaction)
0OK
1WARNING (there are more spending balances than the current POW sender balance in the mempool. An active stance should be taken and perhaps a deeper analysis as to potential conflicts related to the sender.)
2CRITICAL (an active double spend was detected. Any descendant asset allocations are flagged as dangerous and should wait for POW confirmation before proceeding.)

Using Z-DAG Balances#

The available balance while use Z-DAG can be determined by calling assetallocationbalance. If balance and zdag_balance are the same, then display balance. If the balances differ that is an indication that Z-DAG is active for this transaction and it has not yet been confirmed by Proof of Work. In this scenario the zdag_balance should be used to indicate to the user their available balance.

- + \ No newline at end of file diff --git a/docs/dev-resources/tsys/index.html b/docs/dev-resources/tsys/index.html index f56639ad..e2ab8604 100644 --- a/docs/dev-resources/tsys/index.html +++ b/docs/dev-resources/tsys/index.html @@ -6,13 +6,13 @@ SYS/TSYS Faucets | Syscoin Docs - +

SYS/TSYS Faucets

This guide describes how to request funds from the Mainnet and Tanenbaum Testnet faucets.

img

After connecting to the Syscoin Mainnet or Tanenbaum Testnet with MetaMask (tutorial here), head to either one of the below to get some SYS or tSYS as you require, this guide assumes tSYS but applies to Mainnet (SYS) as well:

Copy your address from MetaMask.

img

  • Click the the Tweet link on the faucet page.

img

This will open up Twitter with a Tweet.

img

  • Next, paste in your address replacing the current address then tweet it.

img

  • Once tweeted, click share and copy the tweet link and head back to the faucet page.

img

  • Paste the link into the text box and click Give me SYS. Choose the amount of SYS you would like and wait one block to receive.

img

Your MetaMask Wallet will now be funded with SYS/tSYS and you can now interact with dApps on Syscoin NEVM.

Syscoin Testnet Chain#

In order to access the Syscoin testnet faucet you must first join the Syscoin Discord server.

After doing this, navigate to the #tsys-faucet channel, under the DEVELOPMENT heading.

Then use the command:

!sendme amount address

Where the amount is the amount of tSYS you would like to be sent (maximum 100k at a time), and the address is the Syscoin testnet address you would like the funds sent to.

- + \ No newline at end of file diff --git a/docs/faq/index.html b/docs/faq/index.html index 4545ee4e..0788cb5a 100644 --- a/docs/faq/index.html +++ b/docs/faq/index.html @@ -6,13 +6,13 @@ FAQ | Syscoin Docs - +

FAQ

If your question isn't answered here, please don't hesitate to ask our community!

How do I add Syscoin to MetaMask?#

You can add Syscoin to MetaMask using the table below. If this fails for any reason then please follow the guide here. Welcome to Syscoin!

Network
Rollux L2 Mainnet
Rollux L2 Testnet
Syscoin NEVM Mainnet
Syscoin NEVM Tanenbaum (Testnet)

Get started on Rollux at the Rollux Help Center.

What is Syscoin?#

Syscoin is the Bitcoin-Powered ecosystem securing rollups (L2s and L3s) with unmatched data availability. Syscoin gives superpowers to Bitcoin by providing it the ultimate functionality of a modular execution layer.

What are modular blockchains such as Syscoin?#

The new paradigm is focused on modular blockchains. Rather than trying to achieve everything (scalability, decentralization, security) on a single layer (monolithic) blockchain, modularity involves multiple layers, where each layer is optimized to a specific purpose. Syscoin, the security-focused base layer, provides guarantees of ultimate security and decentralization to all the super fast low-cost layers that are built on top or that are integrated with Syscoin’s zkDA.

How does Syscoin provide scalability?#

Our unique data availability helps scaling layers offer their users fees reduced over 1000% and the ability to provide practically limitless throughput with successive layers. Soon, further advancements such as Syscoin’s zkDA will enable other ecosystems to inherit the security of Syscoin’s data availability plus interoperability with all other ecosystems utilizing it.

What are some rollups that use Syscoin?#

Rollux is an OPStack (Optimism-based) L2 rollup that is EVM-equivalent and utilizes Syscoin’s data availability. Rollux also provides native data availability based on Syscoin, enabling L3s on top of it. Cartesi enables application-specific rollups with a Linux runtime, transcending EVM limitations, and utilizes validity (zk) proofs and Syscoin’s data availability.

How does Syscoin help Bitcoin?#

In multiple ways! First, it’s important to understand that we view Bitcoin as the world’s premier and most-proven secure means of decentralized self-sovereign digital ownership and transfer. That same decentralized security provided by Bitcoin’s Proof-of-Work network of miners is extensible through a process called merged mining, which Satoshi himself created and introduced to Bitcoin Core in 2010. This means Bitcoin’s network is capable of supporting far more than just storing and sending some BTC or an ordinal. In fact, technically it can already support everything Ethereum can, and more, without any Core protocol changes. However, for Bitcoin’s network to tap into this, an appropriately designed merge-mined modular blockchain is required, and Bitcoin miners need to support it. This is where Syscoin comes in.

Syscoin also helps Bitcoin by incentivizing Bitcoin’s miners with the utility coin $SYS. While BTC rewards continue to diminish, the Bitcoin miners who merge-mine Syscoin get the additional $SYS incentive at practically no extra cost. That incentive is tied to limitless utility, and this helps them to continue to support Bitcoin and keep its network decentralized indefinitely into the future.

Do any large Bitcoin mining pools support Syscoin?#

Yes. Three of the top five Bitcoin mining pools, and some smaller pools, already contribute their total Bitcoin hashrate to the Syscoin ecosystem through merged mining. At the present time Syscoin’s hashrate typically reflects 50 to 60% of Bitcoin’s total hashrate. We are happy to assist additional pools with merge-mining so they can provide $SYS to their miners at practically no extra cost.

Is merged mining secure? What about selfish mining?#

At the very least, merge-mining brings the same challenges as standard Proof-of-Work. However, there are important considerations here beyond just the distribution of hashrate supporting the chain. Ultimately, whether a merge-mined chain is secure depends upon that chain’s own protocol. Syscoin is the first blockchain to make merged mining truly secure. This is accomplished by providing an additive layer of decentralized finality on top of the work of Bitcoin’s miners. This is accomplished by a vast network of independently operated non-authoritative incentivized Sentry full nodes which participate in randomized multi-quorums to provide chainlocks. This actually makes Syscoin far more difficult to 51% attack or “selfishly mine” than Bitcoin itself while still keeping Bitcoin’s own PoW at the bottom of the stack. Even if only a single pool mined Syscoin, an attack would still require that pool to control a supermajority of all Sentry nodes, a practically impossible achievement. This finality, which the Bitcoin parent-chain lacks, makes possible the unique data availability we provide to Bitcoin’s community, and so much more that Syscoin provides.

What is $SYS used for and where can I get it?#

Don’t blow your finite BTC on gas fees for execution! Syscoin's native coin, $SYS, is used across the ecosystem for gas and transaction fees and to incentivize Bitcoin’s miners who support Syscoin as well as the Sentry nodes that further enhance Syscoin’s security. This coin is very similar to ETH in supply characteristics and deflationary dynamics. Acquire $SYS by heading to the Get SYS page!

Where can I learn more about Syscoin's design and/or the philosophy behind it?#

Our Foundation President and Lead Core Developer maintains a Medium covering much of this in-depth and with some technical detail. Also, numerous interviews and Spaces have been held over the years with the various Syscoin teams, and can be found by searching X or Youtube.

- + \ No newline at end of file diff --git a/docs/guides/governance/index.html b/docs/guides/governance/index.html index 2d721ead..fc2cd808 100644 --- a/docs/guides/governance/index.html +++ b/docs/guides/governance/index.html @@ -6,13 +6,13 @@ Decentralized Governance | Syscoin Docs - +

Decentralized Governance

The Syscoin protocol provides the Syscoin community the means to participate in decentralized governance. Very similar to the governance of Dash, Syscoin gives Sentry owners the power to vote on proposals that are seeking funding from a monthly superblock emission. Proposals can be submitted by anyone.

Check back for more details and detailed walkthroughs! Until then, suffice to say, the details and process of participating are practically identical to those of Dash governance.

Sysnode.info provides a very useful governance dashboard that makes it easier to participate in Syscoin governance.

- + \ No newline at end of file diff --git a/docs/guides/mining_setup/index.html b/docs/guides/mining_setup/index.html index 206cd341..f03014fb 100644 --- a/docs/guides/mining_setup/index.html +++ b/docs/guides/mining_setup/index.html @@ -6,7 +6,7 @@ Merged Mining Setup Guide | Syscoin Docs - + @@ -29,7 +29,7 @@
rpcuser=user
rpcpassword=pass
rpcallowip=127.0.0.1

For mainnet, set parameter testnet=0 and comment out or omit [test].

There are additional gethcommandline settings to explore here.

Pools that have questions or need assistance with setting-up merged-mining Syscoin should reach out to us via our official Discord server.

Cloud Mining#

You can bring your own hash power or rent it from a third-party. By renting, miners don’t have to worry about equipment setup or maintenance - they only need to configure the target mining pool and voilá!

Getting Started with Mining-Dutch#

Every mining pool has very specific parameters. We are using Mining-Dutch (third-party) for the purpose of this guide. Please follow the getting started instructions before continuing.

Cloud Merged Mining with Mining Rig Rentals (MRR)#

First, add funds to your account.

Then, navigate to “Favorite Pools”, click "Add Pool", and fill as follows:

- Name: Mining-Dutch 256

- Type: Sha256 or Sha256 Asicboost (experimental)

Hit “Save”. It will complain about incomplete info, confirm saving for now.

Go to the SHA-256 section and select a rig of your choice. Click “Rent Now!” then click “Next” and it will render a new Profile form. Select the existing pool from the dropdown and open a new tab or window for Mining-Dutch getting started page. Scroll down to “Miner settings generator”. Pick the closest location to the rig you are renting and enter the matching hash power. Then, scroll down to “Miner configuration settings”. Go back to the MRR tab or window and complete the remaining fields. For example:

- Pool Host:Port: sha256.mining-dutch.nl:9996

- Workername: myuser.worker1

- Password: p=2428

- Notes: (optional)

Hit “Add pool”, click “Next” and review the contract. It will show like this:

Click “Pay and Start” when you are ready. It should start mining immediately. To double go to “My Rentals” from MRR main menu. Also, go to Mining-Dutch workers page for monitoring mining details. You will notice that Mining-Dutch does merged mining of many other altcoins along with Syscoin and might even switch across different blockchains for optimizing earnings (Multiport mode).

Earnings#

Enter the “Earnings” page from Mining-Dutch, balances for every coin you are mining will be updated automagically as new blocks are found. For example:

Other Cloud mining providers#

Some entry-level providers like MMR allow short term and low hash power rentals for about US$5.00. NiceHash rentals start at about US$100.00 at the time of writing. We highly recommend you to perform your own due-diligence and market research.

- + \ No newline at end of file diff --git a/docs/guides/nevm/metamask/index.html b/docs/guides/nevm/metamask/index.html index 912b9850..bea8e9ad 100644 --- a/docs/guides/nevm/metamask/index.html +++ b/docs/guides/nevm/metamask/index.html @@ -6,13 +6,13 @@ Add to MetaMask | Syscoin Docs - +

Add to MetaMask

You can add the Syscoin networks to MetaMask using the table below. If this doesn't work for any reason you can either follow the first guide to use chainlist.org, or you can enter the information manually further down the page. Welcome to Syscoin!

Network
Syscoin NEVM Mainnet
Syscoin NEVM Tanenbaum (Testnet)

Install the MetaMask Extension from the Store#

Visit the browser extension marketplace and download the MetaMask extension.

img

Create a MetaMask Wallet or Import One#

We would suggest creating a new one if you haven’t done so.

img

Click import wallet if you have an existing wallet.

Set up your password and secret recovery phrase somewhere safe.

Quick Auto Setup to connect to Syscoin Network#

Head to https://chainlist.org/ and click Connect Wallet.

img

Once Connected, search for Syscoin in the search bar.

img

Click Add to MetaMask on the relevant network. This should be Syscoin Mainnet, unless you would like to test things out on the Syscoin testnet first.

You have now connected to the Syscoin Mainnet with your Metamask Wallet! You can now interact with dApps on Syscoin NEVM.

Manual Setup to connect to Syscoin Network#

Switch the connected blockchain by clicking on the tab saying Main Ethereum Network, we need to add the Syscoin network.

img

Scroll down until you find Custom RPC.

img

Enter in the Syscoin NEVM Mainnet or Testnet settings as follows:

Mainnet#

Testnet#

The testnet uses test SYS (tSYS), which has no value and is used for testing code before deploying it on mainnet. There is no need to add this network if you don't want to test anything.

Once this information has been entered click Save.

You have now connected to the Syscoin Mainnet with your Metamask Wallet! You can now interact with dApps on Syscoin NEVM.

Transactions on the Syscoin Mainnet require SYS which will be used as a gas fee.

Likewise, transactions on the testnet use tSYS for gas fees.

Get some tokens from the following faucets to use as gas for transactions:

Mainnet (SYS)

Testnet (tSYS)

- + \ No newline at end of file diff --git a/docs/guides/nevm/sysgeth/index.html b/docs/guides/nevm/sysgeth/index.html index d86822f3..1b2a8d4f 100644 --- a/docs/guides/nevm/sysgeth/index.html +++ b/docs/guides/nevm/sysgeth/index.html @@ -6,7 +6,7 @@ Syscoin Geth (sysgeth) | Syscoin Docs - + @@ -16,7 +16,7 @@ zmqpubnevm=""

Connecting to Sysgeth#

With the above configuration, we can then connect using sysgeth to start up the javascript console. First, we need to locate the sysgeth binary, which is located in the Syscoin data directory by default. On Linux box, that would be under ~/.syscoin/

Then, we can simply run the binary and attach it to the running sysgeth using attach on the .ipc

cd ~/.syscoin
./sysgeth attach ~/.syscoin/testnet3/geth/geth.ipc

📘Note#

The location of sysgeth is by default in the base directory of the syscoin datadir, where as the geth.ipc file will be in either [syscoin datadir]/geth/geth.ipc or [syscoin datadir]/testnet3/geth/geth.ipc depending on whether you're running mainnet or testnet

- + \ No newline at end of file diff --git a/docs/guides/overview/index.html b/docs/guides/overview/index.html index 95ab56be..0436fe71 100644 --- a/docs/guides/overview/index.html +++ b/docs/guides/overview/index.html @@ -6,13 +6,13 @@ Overview | Syscoin Docs - +

Overview

There are a number of guides available for users of Syscoin. Check the list below to find what you need. If there is something missing that you would like added please let us know in the Syscoin Discord!

NEVM Guides#

Rollux Guides#

Syscoin Platform Token (SPT) Guides#

Sentry Nodes Guides#

Merged-mining Guides#

- + \ No newline at end of file diff --git a/docs/guides/rollux/metamask/index.html b/docs/guides/rollux/metamask/index.html index dc152d16..dbfe97f7 100644 --- a/docs/guides/rollux/metamask/index.html +++ b/docs/guides/rollux/metamask/index.html @@ -6,13 +6,13 @@ Add to MetaMask or install Pali Wallet | Syscoin Docs - +

Add to MetaMask or install Pali Wallet

Looking for simple instructions to connect to Rollux? Head to the Rollux Help Center!

Once you're connected you can...

  • Move your SYS to Rollux using the Rollux Portal, Rollux's canonical bridge.
  • Use a Rollux faucet to get a small amount of SYS to cover a fee or two on Rollux.
  • Get going with some dapps on Rollux such as Pegasys DEX, Luxy NFT Marketplace, or any other live dapps in the Rollux ecosystem!
- + \ No newline at end of file diff --git a/docs/guides/sentrynode_setup/index.html b/docs/guides/sentrynode_setup/index.html index 6b5a6750..2bae8971 100644 --- a/docs/guides/sentrynode_setup/index.html +++ b/docs/guides/sentrynode_setup/index.html @@ -6,7 +6,7 @@ Sentry Node Setup Guide | Syscoin Docs - + @@ -15,7 +15,7 @@ 2. A Seperate BLS Key per node. 3. An Owner and Voting Key

You can not use the same BLS Key or Owner, Voting Keys for multiple nodes!

Below are the minimum requirements for your VPS. Please do not try to compile without the minimum. You must install on a fresh new VPS.#

  • 64-bit CPU — 2 Cores (4 preferred)
  • 4gb RAM (real) minimum (8gb RAM preferred)
  • 4gb swap (if less than 8gb real RAM) Will need to use SSD if using Swap
  • KVM or OpenVZ (KVM preferred)
  • Linux OS — Minimum Ubuntu 18.04, LTS Ubuntu 20.04 LTS (Focal Fossa) preferred.
  • 80gb Disk Space (100gb+ SSD preferred).

If using an existing address with seniority you will have to manually ‘lock’ the collateral. Do this via Coin Control - right click your 100k tx and click “Lock Unspent”. You do not need to make a new transaction. Doing so will lose your Seniority. If setting up a Sentry Node with a seniority address you can skip to generating your BLS KEYS.

Video Walkthrough#

Sentry Node Install Guide

VPS Providers#

There are many VPS service providers that offer and exceed the hardware requirements, as such it is recommended that you shop around and do your own homework on various potential providers. Note the following is a list of just some examples and should not be interpreted as recommendations or endorsement.

Sentry Node HELP#

Syscoin Discord: If you require more help, jump into the Syscoin Discord and our community will be more than happy to help you out!

Sysnode.info: This website has an array of tools such as Sentry Node Stats, Monitoring and keeping up to date with current news with Syscoin.

Prepare QT and Send 100k Syscoin#

To stake your Sentry Node you will need to provide exactly 100,000 SYS in your Sentry Node address. Use Syscoin Core Qt for your system to process this transaction.

Create a new address for collateral this does not need to be a legacy address anymore, or you can use an existing seniority address. If you are using an existing Seniority Address you do not have to make a new transaction or create a new address.

getnewaddress mn1

Send exactly 100,000 Syscoin to this address.

Identify 100k Syscoin Transaction#

  • Click Window>Console and enter the following command: Note some commands now require an underscore
masternode_outputs

This should return a string of characters similar to the following:

{
"3304a4920f20e1e5cd1f34e5396556ded1e603296f7c5dd66c7ec4fe63cb008d": "0"
}

The first long string is your collateralHash, while the last number is the collateralIndex.

Generate BLS Key Pair#

NOTE: YOU MUST CREATE A BLS KEY PAIR FOR EVERY NODE

A public/secret BLS key pair is required to operate a Sentry Node. The secret key is specified on the Sentry Node itself, and allows it to be included in the deterministic Sentry Node list once a provider registration transaction with the corresponding public key has been created.

If you are using a hosting service, they may provide you with their public key, and you can skip this step. If you are hosting your own Sentry Node or have agreed to provide your host with the BLS secret key, generate a BLS public/secret keypair in the Console and entering the following command:

These keys are NOT stored by the wallet and must be kept secure, similar to the value provided in the past by the Sentry Node genkey command.

bls_generate
{
"secret": "1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7",
"public": "05afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de"
}

Configure Sentry Node on VPS#

Finally we are ready to work on your server. Connect to your VPS as root via SSH (Putty) and enter the following command to start the automated install:

bash <(curl -sL https://raw.githubusercontent.com/Syscoin/Masternode-install-script/master/script.sh)

Please also check the latest releases - if it is not 4.3.0, you will need to enter in the latest release tag for for Syscoin Core Github Branch. So if the latest release is 4.3.1, you would enter 4.3.1 and then press enter. You can check that here; Releases · syscoin/syscoin · GitHub

Default values are found in brackets and pressing enter will selected the [default] value. For entries with a [Y/n] the capital letter is the default. Enter [Y] to choose “yes” or [N] to choose “no”. Likely the only value you will need to enter is the latest release tag and Sentry Node BLS Secret key.

Syscoin Core Github Branch [master]: enter latest release tag here. For eg. 4.3.0
External IP Address [123.123.123.123]:
Masternode Port [8369]:
Masternode BLS Secret Key []: 1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7
Configure for mainnet? [Y/n]:
Press any key to continue or Ctrl+C to exit...

Once the build process and configuration have completed, to access the syscoind and syscoin-cli executables via the new syscoin user type the below into cmd; source ~/.bashrc

To check on sync status type; syscli mnsync status

Now head to your Syscoin QT to Register your Sentry Node

Prepare a ProRegTx transaction#

A pair of BLS keys for the operator were already generated above, and the secret key was entered on the Sentry Node. The public key is used in this transaction as the operatorPubKey

First, we need to get a new, unused address from the wallet to serve as the owner key address ownerKeyAddr. This is not the same as the collateral address holding 100,000 Syscoin. This address must be different for each MN.

Generate a new address as follows:

getnewaddress mn1-owner

This address can also be used as the voting key address votingKeyAddr. Alternatively, you can specify an address provided to you by your chosen voting delegate, or simply generate a new voting key address as follows:

getnewaddress mn1-voting

Then either generate or choose an existing address to receive the owner’s Sentry Node payouts payoutAddress. This address cannot be the same as your owner or voting address, it is also possible to use an address external to the wallet:

getnewaddress payouts

You can also optionally generate and fund another address as the transaction fee source feeSourceAddress. If you selected an external payout address, you must specify a fee source address.

Either the payout address or fee source address must have enough balance to pay the transaction fee, or the register_prepare transaction will fail.

The private keys to the owner and fee source addresses must exist in the wallet submitting the transaction to the network. If your wallet is protected by a password, it must now be unlocked to perform the following commands. Unlock your wallet for 5 minutes:

walletpassphrase yourSecretPassword 300

Donate to the Syscoin Foundation#

When Registering your Syscoin Sentry Node in the next step you have the option to donate a percentage of your rewards to someone else via the operatorReward argument. Please help support the team and choose an amount that you are happy to donate such as 5% to 10%. By doing this you help the efforts of the Foundation on creating a solid network and the continued development of Syscoin. If you do select an amount, there will be an extra step at the end of the tutorial that you will need to complete via Syscoin QT console. The team thanks you in advance for your continued support.

Register ProTx#

We will now prepare an unsigned ProRegTx special transaction using the protx_register_prepare command.

This command has the following syntax:

protx_register_prepare collateralHash collateralIndex ipAndPort ownerKeyAddr operatorPubKey votingKeyAddr operatorReward payoutAddress (feeSourceAddress)

Open a text editor such as notepad ++ to prepare this command or head to SysHub Sentry Node Registration.

Replace each argument to the command as follows:

  • collateralHash: The txid of the 100000 Syscoin collateral funding transaction
  • collateralIndex: The output index of the 100000 Syscoin funding transaction
  • ipAndPort: Sentry Node IP address and port, in the format x.x.x.x:yyyy
  • ownerKeyAddr: The Syscoin address generated above for the owner address
  • operatorPubKey: The BLS public key generated above (or provided by your hosting service)
  • votingKeyAddr: The Syscoin address generated above, or the address of a delegate, used for proposal voting
  • operatorReward: The percentage of the block reward allocated to the operator as payment, 0 for no reward - this is if you want to pay someone else a % of your rewards. This is the part where if you would like to donate to the Syscoin Foundation.
  • payoutAddress: A Syscoin address to receive the owner’s Sentry Node rewards.
  • feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified.

Note that the operator is responsible for specifying their own reward address in a separate update_service transaction if you specify a non-zero operatorReward. The owner of the Sentry Node collateral does not specify the operator’s payout address.

Either the feeSourceAddress or payoutAddress must hold a small balance since a standard transaction fee is involved. Example (remove line breaks if copying):

Note in this example I will use the same address for owner and voting and i will have sent a small amount of Sys to the payoutAddress for fees as i am not using feeSourceAddress.

(Remember to lock your collateral if using a seniority address)

Output:
{
"tx": "5000000000010163dc2d9a36a7a620386a23002ab6b8a2aba0956e7e047b73a6cf27d9d51571e80100000000feffffff020000000000000000d16a4cce0100000000008d00cb63fec47e6cd65d7c6f2903e6d1de566539e5341fcde5e1200f92a404330000000000000000000000000000ffffa1618f4447c12f73258d961fe6082720ecc7415d4ebebdadb37905afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de2f73258d961fe6082720ecc7415d4ebebdadb3790000160014e7395ee2f4986418b03bee442c2f051c6357d0318e95079d496ed43baba5101dab0ab5ace776ac1b0b7fcba7711a2504c9ea36610074c89a3b00000000160014279a7a94c83130b3eee07f2c66b2faa94b6cfe990247304402201f1e01ab33d4f388386ca5df94818674cf4b1909806c3a92ffc11ded88d84dfb02206d289cca1fbd19bc5154c85ec4f1eb3748f77071d863ae4f6aa18f56807f76e801210298a88bd8293e4d0248eb89f276cb54c26b3686ea4e17df155a22bfed2426862800000000",
"collateralAddress": "TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG",
"signMessage": "sys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0"
}

Next we will use the collateralAddress and signMessage fields to sign the transaction, and the output of the tx field to submit the transaction.

Sign the ProRegTx transaction#

We will now sign the content of the signMessage (returned above) field using the public key for the collateral address as specified in collateralAddress. The wallet used to sign must hold the private key to the collateral address and note that no internet connection is required for this step, meaning that the wallet can remain disconnected from the internet in cold storage to sign the message.

The command takes the following syntax:

signmessagebech32 collateralAddress signMessage

Example: (excluding “ ”)

signmessagebech32 TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0

Output: IGj1ORdk3yv/uAMKG+DZrBA/GTHX4dW8zn/rmMfGzOzCIaxqmyUbNveYtnqh9wLVECENMjyuyeR2VmB3ccNlRLw=

Submit the signed message#

We will now submit the ProRegTx special transaction to the blockchain to register the Sentry Node. This command must be sent from the wallet holding a balance on either the feeSourceAddress or payoutAddress, since a standard transaction fee is involved.

The command takes the following syntax:

protx_register_submit tx sig

Where: tx: The serialized transaction previously returned in the tx output field from the protx_register_prepare command sig: The message returned from the signmessagebech32 command.

Example: (excluding “ ”)

protx_register_submit 5000000000010163dc2d9a36a7a620386a23002ab6b8a2aba0956e7e047b73a6cf27d9d51571e80100000000feffffff020000000000000000d16a4cce0100000000008d00cb63fec47e6cd65d7c6f2903e6d1de566539e5341fcde5e1200f92a404330000000000000000000000000000ffffa1618f4447c12f73258d961fe6082720ecc7415d4ebebdadb37905afc5f75d0a215951677703e41a108a67f2efb31110e392d988dbd4f9e8446a3336d59de1ff886ec0d3c65c822af2de2f73258d961fe6082720ecc7415d4ebebdadb3790000160014e7395ee2f4986418b03bee442c2f051c6357d0318e95079d496ed43baba5101dab0ab5ace776ac1b0b7fcba7711a2504c9ea36610074c89a3b00000000160014279a7a94c83130b3eee07f2c66b2faa94b6cfe990247304402201f1e01ab33d4f388386ca5df94818674cf4b1909806c3a92ffc11ded88d84dfb02206d289cca1fbd19bc5154c85ec4f1eb3748f77071d863ae4f6aa18f56807f76e801210298a88bd8293e4d0248eb89f276cb54c26b3686ea4e17df155a22bfed2426862800000000 IGj1ORdk3yv/uAMKG+DZrBA/GTHX4dW8zn/rmMfGzOzCIaxqmyUbNveYtnqh9wLVECENMjyuyeR2VmB3ccNlRLw=

Output:

285fba6277586401f8efaf55d4eef7acfa6d690a30c0db7f213a0bb2c6194bd1

Your Sentry Node is now registered and will appear on the Deterministic Sentry Node List after the transaction is mined to a block.

You can view this list on the Sentry Nodes tab in QT, or in the console using the command protx_list valid, where the txid of the final protx_register_submit transaction identifies your Sentry Node.

Specifying donation address for operatorReward (optional)#

Syscoin Foundation Address: sys1q6u9ey7qjh3fmnz5gsghcmpnjlh2akem4xm38sw

You only need to do this if you input a value greater than 0 when completing the ProRegTx for operatorReward.

protx_update_service proTxHash ipAndPort operatorKey (operatorPayoutAddress feeSourceAddress)

Where:

  • proTxHash: The hash of the initial ProRegTx
  • ipAndPort: IP and port in the form “ip:port”
  • operatorKey: The operator BLS private key associated with the registered operator public key
  • operatorPayoutAddress: The address used for operator reward payments.
  • feeSourceAddress (optional): An address used to fund ProTx fee. operatorPayoutAddress will be used if not specified.

Example:

protx update_service 285fba6277586401f8efaf55d4eef7acfa6d690a30c0db7f213a0bb2c6194bd1 161.97.140.65:8369 1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7 sys1q6u9ey7qjh3fmnz5gsghcmpnjlh2akem4xm38sw

SENTRY NODE COMMANDS#

view your syscoin.conf#
sudo cat /home/syscoin/.syscoin/syscoin.conf
view your sentinel.conf#
sudo cat /home/syscoin/sentinel/sentinel.conf
view the syscoin user crontab which should contain:#
sudo crontab -u syscoin -l
run a sentinel ping to speed up Qt syncing? why not!#
sudo su -c "sentinel-ping" syscoin
view the sentinel-ping cron log, look for errors#
sudo less /home/syscoin/sentinel/sentinel-cron.log
view the syscoind debug log, look for errors#
sudo less /home/syscoin/.syscoin/debug.log
start and stop the syscoind systemd service#
sudo service syscoind stop
sudo service syscoind start
sudo service syscoind restart
check that the syscoind process is running at the proper user#
ps aux | grep [s]yscoind
log out and back in or run the following to alias syscoind and syscoin-cli#
source ~/.bashrc
now the commands run as the syscoin user#
syscoin-cli getblockchaininfo
syscoin-cli mnsync status
syscoin-cli masternode_status
it is aliased to this shorter function#
syscli getblockchaininfo
syscli mnsync status
syscli masternode_status
if you really want to log in as the syscoin user#
sudo su - syscoin
- + \ No newline at end of file diff --git a/docs/guides/spts/aux-fees/index.html b/docs/guides/spts/aux-fees/index.html index fb13b2b9..618d9800 100644 --- a/docs/guides/spts/aux-fees/index.html +++ b/docs/guides/spts/aux-fees/index.html @@ -6,7 +6,7 @@ Auxiliary Fees | Syscoin Docs - + @@ -14,7 +14,7 @@

Auxiliary Fees

info

UPDATE: The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4.
Now syscoinjs-lib and syscointx-js are used to create/manage digital assets, auxfees, and notaries on the UTXO chain.

Examples are available at https://github.com/syscoin/syscoinjs-lib-examples.

For a complete list of these deprecated RPCs, review the Syscoin Core 4.4 release notes.

Auxiliary Fees lets you define a custom fee structure for your token. These transaction fees are calculated according to the specified structure and paid to the designated Syscoin address in the form of the transacted Syscoin Platform Token (SPT). Standard network fees paid in SYS still apply.

Understanding auxfee_details#

Example auxfee_details:

'{"auxfee_address": "tsys1qgklj8wcyss87q2wgr84ypfj0fxtahe60788tad", "fee_struct": [[0,0.01],[10,0.004],[250,0.002],[2500,0.0007],[25000,0.00007],[250000,0.000007]]}'

auxfee_address: where transaction fees will be sent. fee_struct: the first integer represents a range boundary pertaining to amount. The second is the fee percentage multiplier for that range. Multiple ranges can be defined in order from least to greatest boundary integer.

Calculation is cumulative across the amount boundaries.

For example, the auxiliary fee for a transaction of 251 tokens with the above fee structure would be calculated as follows:

(10 * 0.01) + (240 * 0.004) + (1 * 0.002) = 1.062 total tokens

Implementation#

The auxfee_details structure can be defined within the RPC parameters of assetnew and assetupdate.

Auxfee_details defined in assetnew parameter:

$syscoin-cli assetnew 100 "AUXF" "auxFee Test Token" "" 8 1000000 127 "" {} '{"auxfee_address": "tsys1qgklj8wcyss87q2wgr84ypfj0fxtahe60788tad", "fee_struct": [[0,0.01],[10,0.004],[250,0.002],[2500,0.0007],[25000,0.00007],[250000,0.000007]]}'

📘auxfee_details structure is stored in the auxfee field#

and corresponds to updatecapability_flags bitmask value 32

- + \ No newline at end of file diff --git a/docs/guides/spts/create-issue-tokens/index.html b/docs/guides/spts/create-issue-tokens/index.html index b6649dc8..3ba16385 100644 --- a/docs/guides/spts/create-issue-tokens/index.html +++ b/docs/guides/spts/create-issue-tokens/index.html @@ -6,7 +6,7 @@ Create/Issue Tokens | Syscoin Docs - + @@ -31,7 +31,7 @@
{
"txid": "737abcbfa2d42e2188966343b169442c8067c82d133a39d27ad56015076376cf",
"assetallocations_sent_count": 1,
"assetallocations_sent": [
{
"asset_guid": 56167720748738,
"base_asset_guid": 2433418946,
"NFTID": 13077,
"amount": 0.12725100,
"sys_amount": 0.00000980
}
]
}

4b(ii). How to Issue and Transfer a Non-Fractional Non-Fungible Token#

In this example we will start with a testnet asset representing the inventory of an art vault.

$ syscoin-cli assetinfo 389115219
{
"asset_guid": 389115219,
"symbol": "VAULT9",
"public_value": {
"desc": "Fitzstephen Co. Art Vault #9"
},
"contract": "",
"notary_address": "",
"total_supply": 0.00000000,
"max_supply": 288.0,
"updatecapability_flags": 127,
"precision": 0
}

This asset was defined with a precision of 0 and a max supply of 288, because there are 288 art pieces held in the vault, and ownership of each of these will be transferred to one owner as a non-divisible token representing the entirety of the piece

📘Note#

You can also create an asset with precision 0 and max supply 1, effectively making the primary asset itself a non-divisble NFT. However, it's often more intuitive to issue multiple unique non-divisible tokens from a single parent asset (the inventory). This is more cost effective as you pay the asset creation fee only once (1 SYS) and are able to issue a quantity of unique child NFT's up to the max supply of the parent asset, only paying the comparatively small fee associated with assetsend for each new NFT.

Children assets inherit the attributes of the parent and are unique only by their NFTID and deterministic child assetGUID. If you want each NFT you issue to use a different Notary API, on-chain description, etc, you would use assetnew and pay the asset creation fee for each of them.

Issue one of the art pieces into the new owner's possession with assetsend in the amount of 1 token, and assign the NFTID (your own numeric identifier representing the art piece), in this case 14, your inventory number for Andy Warhol's original Self Portrait. We'll also send the new owner a small amount of SYS for gas to be used in the future (0.000098).

$ syscoin-cli assetsend 389115219 "tsys1qktelej8knjvc5nfpka2evnwyfsw6ltqnhd9k2f" 1.0 0.0000098 14
{
"txid": "4ef2b4f0a807f2542567cc79201ddf8b22aadb0156ac54313cd0e186ef210296",
"assets_issued_count": 1,
"assets_issued": [
{
"asset_guid": 4684082515,
"base_asset_guid": 389115219,
"NFTID": 14,
"amount": 1.0,
"sys_amount": 0.00000980
}
]
}

The new owner can now transfer ownership using assetallocationsend with <asset_guid> 4684082515

- + \ No newline at end of file diff --git a/docs/guides/spts/notary-business-rulesets/index.html b/docs/guides/spts/notary-business-rulesets/index.html index 8d6976a7..88307c73 100644 --- a/docs/guides/spts/notary-business-rulesets/index.html +++ b/docs/guides/spts/notary-business-rulesets/index.html @@ -6,7 +6,7 @@ Notary and Business Rulesets | Syscoin Docs - + @@ -14,7 +14,7 @@

Notary and Business Rulesets

info

UPDATE: The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4.
Now syscoinjs-lib and syscointx-js are used to create/manage digital assets, auxfees, and notaries on the UTXO chain.

Examples are available at https://github.com/syscoin/syscoinjs-lib-examples.

For a complete list of these deprecated RPCs, review the Syscoin Core 4.4 release notes.

You can require that allocations of your asset meet rules you define in order to be notarized and allowed to settle on-chain. With a Notary endpoint, any allocation of the asset must pass the endpoint's checks to be granted a notary signature and be accepted into a block.

This general-purpose feature is particularly useful for ensuring asset transactions are compliant with regulations prior to receiving approval. It can also be used to add an optional trust-based security domain for expedited service.

You can read more about the design and philosophy behind this capability here.

To begin, let's look at an asset notary example; Asset GUID 1815902629.

> syscoin-cli assetinfo 1815902629
{
"asset_guid": "1815902629",
"symbol": "FANCY",
"public_value": {
"desc": "NFT with auxfees and notary"
},
"contract": "",
"notary_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q",
"notary_details": {
"endpoint": "https://116.203.116.18:8081/notarize",
"instant_transfers": 1,
"hd_required": 0
},
"auxfee": {
"auxfee_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q",
"fee_struct": [
{
"bound": 0.00000000,
"percentage": 0.01
},
{
"bound": 10.00000000,
"percentage": 0.004
},
{
"bound": 250.00000000,
"percentage": 0.002
},
{
"bound": 2500.00000000,
"percentage": 0.0007
},
{
"bound": 25000.00000000,
"percentage": 6e-05
},
{
"bound": 250000.00000000,
"percentage": 0
}
]
},
"total_supply": 10.00000000,
"max_supply": 9999.00000000,
"updatecapability_flags": 127,
"precision": 8
}

Relevant Fields#

notary_address (string)#

Public key of the endpoint's notary signer. Typically an address chosen by the issuer for which the Notary holds the private key. If specified, the private key associated with this address must sign any transaction of this asset in order for the network to accept it into a block.

notary_details.endpoint (string)#

API endpoint URL.

When a client executes assetallocationsend, an HTTP POST is sent to the endpoint specified here and the client awaits a response. Response timeout is 15 seconds.

The client's POST provides the endpoint a raw transaction hex which the notary then decodes, parses, then logically processes.

The endpoint URL can point to any application or script of any language that can receive and process POST requests and provide an appropriate JSON response. The endpoint must return details of a successfully notarized (signed) transaction broadcasted to the network or the client's request is considered failed or rejected.

Endpoint programs can interact with Syscoin by making RPC calls directly to a Syscoin Core instance (see syscoin-js), or through a Web3 approach by using a combination of syscoinjs-lib and Syscoin Blockbook.

A rudimentary example of a notary endpoint script is available here.

notary_details.instant_transfers (boolean)#

This flag indicates whether the notary is offering a guarantee of extra security in prevention of double spends. Recipients can instantly redeem/spend notarized inputs if they fully trust the notary's security.

This security path theoretically can provide payment service even faster than Z-DAG's decentralized relay and is based on an optional trust trade-off.

Endpoints can ensure protection against double spends by tracking spend requests of an input and responding to them based on the existence (or lack) of prior spend attempts.

If 0, the notary is not guaranteeing any supplementary security measures and transactors of the asset should rely exclusively upon Z-DAG and/or Syscoin Core consensus.

notary_details.hd_required (boolean)#

This flag indicates the notary requires HD wallet approval (for sender approval specifically applicable to change address schemes), usually in the form of the account XPUB or verifiable credential of the account XPUB using decentralized identity

How to Enable Notary#

An issuer can enable Notary on an asset by setting parameters in assetnew (upon asset creation), or assetupdate (updating the asset spec, if the asset's current update_capabilityflags value permits this).

Enable Notary via assetnew:

> syscoin-cli assetnew 100 "ECASH" "Non-custodial KYC/AML-enabled Electronic Cash" "" 8 888000000 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://116.203.116.18:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {}

Enable Notary via assetupdate:

> syscoin-cli assetupdate 1020176632 "Non-custodial KYC/AML-enabled Electronic Cash" "" 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://116.203.116.18:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {}
- + \ No newline at end of file diff --git a/docs/guides/spts/use-tokens/index.html b/docs/guides/spts/use-tokens/index.html index a1f0c4ea..381990a2 100644 --- a/docs/guides/spts/use-tokens/index.html +++ b/docs/guides/spts/use-tokens/index.html @@ -6,7 +6,7 @@ Use Syscoin 4.2 Tokens | Syscoin Docs - + @@ -28,7 +28,7 @@
Result:
{ (json object)
"txid" : "hex" (string) The transaction id
}
Examples:
> syscoin-cli assetallocationsendmany '[{"asset_guid":1045909988,"address":"sysaddress1","amount":100},{"asset_guid":1045909988,"address":"sysaddress2","amount":200}]' "false"
> syscoin-cli assetallocationsendmany "[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]" "true"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ['[{"asset_guid":1045909988,"address":"sysaddress1","amount":100},{"asset_guid":1045909988,"address":"sysaddress2","amount":200}]',"false"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ["[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]","true"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/' -H 'content-type: text/plain;' http://127.0.0.1:8370/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ["[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]","true"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/
assetallocationsendmany '[{"asset_guid": <assetGUID>, "address": <recipientAddress>,"amount": <amount>, "sys_amount": <amount>},{"asset_guid": <assetGUID>, "address": <recipientAddress>,"amount": <amount>, "sys_amount": <amount>}]' <replaceable (boolean)>

Set argument replaceable to false in order to use Z-DAG.

Allocate one or more assets to multiple addresses:

$ syscoin-cli assetallocationsendmany '[{"asset_guid": 1965866356,"address":"tsys1qecwhh7lckpamavny534xcgrq4z9nm4ckajj9gm","amount":1.55,"sys_amount":0.0000098},{"asset_guid":1965866356,"address":"tsys1ql8h9gknschcwqmehz4hhaykdn6wju8cemj9met","amount":2.75, "sys_amount":0.0000098}]' false
{
"txid": "d6964154f1b11954f86b74953d24e2c79efe6266f9a6e954fdce8d3861b62de2",
"assetallocations_sent_count": 1,
"assetallocations_sent": [
{
"asset_guid": 1965866356,
"amount": 4.30000000,
"sys_amount": 0.00001960
}
]
}
- + \ No newline at end of file diff --git a/docs/intro/nutshell/index.html b/docs/intro/nutshell/index.html index 0154a2bb..0a0f2b4a 100644 --- a/docs/intro/nutshell/index.html +++ b/docs/intro/nutshell/index.html @@ -6,13 +6,13 @@ Syscoin in a Nutshell | Syscoin Docs - +
-

Syscoin in a Nutshell

Mission#

An open source community dedicated to scaling Bitcoin, especially its proof-of-work security, to meet global needs and emerging use-cases, while sticking as close as possible to Bitcoin's original ideals.

Syscoin's evolution across ten years of mainnet and the foresight reflected in its design mean the project has a head-start providing a comprehensive network and protocol for projects aiming to achieve Bitcoin L2. Join us!

The Blockchain Protocol#

Syscoin is a mainnet Bitcoin L2 that provides a data availability protocol that scales, making EVM and AltVM rollups on Bitcoin a reality. Merge-mined by a majority Bitcoin's hashrate, Syscoin anchors rollups to Bitcoin's own proof-of-work and works with rollups’ existing sequencer architectures.

One such rollup is Rollux, an EVM-equivalent OPStack with 2 second blocktimes and negligible fees, which is live.

zkDA and Trustless Interoperability#

Syscoin is currently pioneering zkDA, an upcoming solution that will make Data Availability cross-chain interoperable through ZK light clients. This will make it easy for other blockchains to tap into Syscoin's DA and ultimately Bitcoin's PoW, and to trustlessly interoperate with other ecosystems that do the same.

Decentralized Finality without Slashing#

Data Availability and scaling it require preventing risks of impact from chain re-orgs. Syscoin solves this with a finality mechanism of multi-quorum chainlocks. This creates an additive security layer on top of Bitcoin's PoW. Served by 1,600 randomly selected Sentry nodes, this practically eliminates the risks of re-orgs, 51% attacks and selfish mining, without involving slashing.

Why $SYS?#

Don't blow your finite BTC on gas fees! $SYS is a utility-focused native coin, based upon EIP-1559. SYS incentivizes Bitcoin miners to keep supporting Bitcoin indefinitely into the future despite diminishing BTC rewards. It also incentivizes Syscoin's Sentry nodes.

Diagram#

img

- +

Syscoin in a Nutshell

Mission#

An open source community dedicated to scaling Bitcoin, especially its proof-of-work security, to meet global needs and emerging use-cases, while sticking as close as possible to Bitcoin's original ideals.

Syscoin's evolution across ten years of mainnet and the foresight reflected in its design mean the project has a head-start providing a comprehensive network and protocol for projects aiming to achieve Bitcoin L2. Join us!

The Blockchain Protocol#

Syscoin is a mainnet Bitcoin L2 that provides a data availability protocol that scales, making EVM and AltVM rollups on Bitcoin a reality. Merge-mined by a majority Bitcoin's hashrate, Syscoin anchors rollups to Bitcoin's own proof-of-work and works with rollups’ existing sequencer architectures.

One such rollup is Rollux, an EVM-equivalent OPStack with 2 second blocktimes and negligible fees, which is live.

Decentralized Finality without Slashing#

Data Availability and scaling it require preventing risks of impact from chain re-orgs. Syscoin solves this with a finality mechanism of multi-quorum chainlocks. This creates an additive security layer on top of Bitcoin's PoW. Served by 1,600 randomly selected Sentry nodes, this practically eliminates the risks of re-orgs, 51% attacks and selfish mining, without involving slashing.

Current Research & Development#

  • zkDA, an upcoming solution that will make Data Availability cross-chain interoperable through ZK light clients. This will make it easy for other blockchains to tap into Syscoin's DA and ultimately Bitcoin's PoW, and to trustlessly interoperate with other ecosystems that do the same.
  • SYS Labs and Syscoin Foundation R&D includes Bitcoin L0, crypto-economic security for every facet of Bitcoin L2 through Rollux, and a difficulty-based stBTC.

Why $SYS?#

Don't blow your finite BTC on gas fees! $SYS is a utility-focused native coin, based upon EIP-1559. SYS incentivizes Bitcoin miners to keep supporting Bitcoin indefinitely into the future despite diminishing BTC rewards. It also incentivizes Syscoin's Sentry nodes.

Diagram#

Objects colored gray are in research and development. All others are mainnet.

img

+ \ No newline at end of file diff --git a/docs/intro/syscoin-what/index.html b/docs/intro/syscoin-what/index.html index 1368adec..2cf20445 100644 --- a/docs/intro/syscoin-what/index.html +++ b/docs/intro/syscoin-what/index.html @@ -6,15 +6,15 @@ A More Detailed Overview | Syscoin Docs - +

A More Detailed Overview

What is Syscoin?#

Syscoin is a Bitcoin L2 that is merge-mined with Bitcoin, and a modular Proof-of-Work blockchain solution that brings rollups to Bitcoin's PoW. Syscoin provides to Bitcoin a scalable data availability layer which is necessary for rollups (and other EVM or AltVM layers) to tap into Bitcoin's network in a safe and scalable way. Syscoin's base is comprised of a dual-chain Layer 1: the core is the Syscoin native (UTXO) blockchain providing data availability and finality. Running in tandem with the UTXO chain is an Ethereum Virtual Machine (EVM) chain called NEVM (Network-Enhanced Virtual Machine), which is merged mined alongside the UTXO chain and also inherits finality.

Originally brought to mainnet in 2014, the Syscoin protocol has been improved iteratively, settling into the robust and useful protocol that it is today.

What percentage of Bitcoin's hashrate is supporting Syscoin? Compare to see:
Bitcoin hashrate
-Syscoin hashrate

img

What Syscoin Provides#

  • PoDA - Proof of Data Availability is an L1 DA protocol for rollups. It is hash-based and built on UTXO. Efficient, general purpose, easy to integrate.
  • Rollux - An OPStack rollup anchored to Bitcoin through Syscoin's DA protocol. Provides 2-second blocktime, extremely low fees, and supports application layers on top.
  • NEVM - Network-Enhanced Virtual Machine is the L1 EVM of Syscoin, made specifically for supporting rollups and other scaling layers.
  • Ordinals support - Our native Bitcoin-based UTXO chain remains closely up-to-date with Bitcoin Core and includes support for Taproot/Schnorr. This means there is a great deal of potential here for cross-chain and even cross-architecture (UTXO <-> EVM Rollup) ordinals. Further, our PoDA protocol means ordinal creators can secure data payloads in a new, more efficient way.
  • Sentry Nodes and Finality - Incentivized full nodes deterministically provide finality through multi-quorum chainlocks (4 x 400) as additive security on top of Bitcoin's PoW. Owners of these collateralized nodes receive rewards, including seniority benefits, for the services they provide to the network.
  • Z-DAG - Based upon Satoshi's "snack machine" concept, Z-DAG is a UTXO-based instant settlement protocol with probabilistic security used to enable a very high throughput of UTXO transfers. Works with UTXO-based assets. In a nutshell, it utilizes Bitcoin's mempool design as a DAG by providing double-spend awareness across a mesh topology.
  • Notary rulesets - This allows Syscoin Platform Token (SPT) creators to apply their own rulesets on transfers of their SPT and then accept or deny the transfers by signing or not signing the transactions. These off-chain rulesets enable SPT asset managers to maintain compliance even when regulations or business rules change.

Why Choose Syscoin?#

Security: Syscoin provides manifold security as a settlement and data availability layer for rollups and other scaling solutions. First, leveraging merge-mining with Bitcoin, Syscoin is currently powered by around 60% of Bitcoin's own hashrate. This taps you into the world's best Proof-of-Work network for proven antifragility and fault tolerance as well as resilience against economic black swans, at a level which pure Proof-of-stake systems simply cannot match. Additionally, Syscoin's Sentry nodes provide multi-quorum chainlocks for an additive layer of finality which keeps intact the benefits of Proof-of-work while greatly mitigating the risks of 51% attacks and selfish mining. Furthermore, the security of Syscoin's data availability will soon extend to nearly any blockchain ecosystem through zkDA, a new Syscoin innovation in-progress that also brings a new level of cross-chain interoperability. All of this underscores Syscoin's commitment to robust security.

Scalability: With a unique and holistically modular design, Syscoin stands out with exceptional support for scalability layers. Providing a live dedicated data availability protocol on Layer 1 means Syscoin is already ideal for natively supporting rollups of all kinds as scaling layers. Rollux, the first rollup built on Syscoin, is a perfect example. Scalability, in this context, extends beyond transaction volume and speed of settlement; it also encompasses the affordability of transactions. Low cost execution makes Syscoin an attractive option for projects seeking a settlement layer for their rollup, especially those aiming to make frequent state commitments. In comparison to other EVM-based chains, Syscoin is more scalable and cost-effective, but that's not all.

Decentralization: The network boasts approximately 2,700 independently owned and operated Sentry nodes which work together deterministically to serve a decentralized finality mechanism. The rewards associated with hosting a Sentry node contribute to their growth and retention, including seniority benefits. Over 75% of these nodes have been active and collateralized for over two and half years. Furthermore, SYS, the native currency of Syscoin, has been in circulation since 2014 and is broadly distributed.

In summary, Syscoin is

  • modular
  • exceptionally secure
  • scalable
  • decentralized
  • flexible
  • economical
  • reliable

Projects that are considering Syscoin, or that have questions, can reach out to the community and teams.

- +Syscoin hashrate

img

What Syscoin Provides#

  • PoDA - Proof of Data Availability is an L1 DA protocol for rollups. It is hash-based and built on UTXO. Efficient, general purpose, easy to integrate.
  • Rollux - An OPStack rollup anchored to Bitcoin through Syscoin's DA protocol. Provides 2-second blocktime, extremely low fees, and supports application layers on top.
  • NEVM - Network-Enhanced Virtual Machine is the L1 EVM of Syscoin, made specifically for supporting rollups and other scaling layers.
  • Ordinals support - Our native Bitcoin-based UTXO chain remains closely up-to-date with Bitcoin Core and includes support for Taproot/Schnorr. This means there is a great deal of potential here for cross-chain and even cross-architecture (UTXO <-> EVM Rollup) ordinals. Further, our PoDA protocol means ordinal creators can secure data payloads in a new, more efficient way.
  • Sentry Nodes and Finality - Incentivized full nodes deterministically provide finality through multi-quorum chainlocks (4 x 400) as additive security on top of Bitcoin's PoW. Owners of these collateralized nodes receive rewards, including seniority benefits, for the services they provide to the network.
  • Z-DAG - Based upon Satoshi's "snack machine" concept, Z-DAG is a UTXO-based instant settlement protocol with probabilistic security used to enable a very high throughput of UTXO transfers. Works with UTXO-based assets. In a nutshell, it utilizes Bitcoin's mempool design as a DAG by providing double-spend awareness across a mesh topology.
  • Notary rulesets - This allows Syscoin Platform Token (SPT) creators to apply their own rulesets on transfers of their SPT and then accept or deny the transfers by signing or not signing the transactions. These off-chain rulesets enable SPT asset managers to maintain compliance even when regulations or business rules change.

Why Choose Syscoin?#

Security: Syscoin provides manifold security as a settlement and data availability layer for rollups and other scaling solutions. First, leveraging merge-mining with Bitcoin, Syscoin is currently powered by around 60% of Bitcoin's own hashrate. This taps you into the world's best Proof-of-Work network for proven antifragility and fault tolerance as well as resilience against economic black swans, at a level which pure Proof-of-stake systems simply cannot match. Additionally, Syscoin's Sentry nodes provide multi-quorum chainlocks for an additive layer of finality which keeps intact the benefits of Proof-of-work while greatly mitigating the risks of 51% attacks and selfish mining. Furthermore, the security of Syscoin's data availability will soon extend to nearly any blockchain ecosystem through zkDA, a new Syscoin innovation in-progress that also brings a new level of cross-chain interoperability. All of this underscores Syscoin's commitment to robust security.

Scalability: With a unique and holistically modular design, Syscoin stands out with exceptional support for scalability layers. Providing a live dedicated data availability protocol on Layer 1 means Syscoin is already ideal for natively supporting rollups of all kinds as scaling layers. Rollux, the first rollup built on Syscoin, is a perfect example. Scalability, in this context, extends beyond transaction volume and speed of settlement; it also encompasses the affordability of transactions. Low cost execution makes Syscoin an attractive option for projects seeking a settlement layer for their rollup, especially those aiming to make frequent state commitments. In comparison to other EVM-based chains, Syscoin is more scalable and cost-effective, but that's not all.

Decentralization: The network boasts approximately 2,700 independently owned and operated Sentry nodes which work together deterministically to serve a decentralized finality mechanism. The rewards associated with hosting a Sentry node contribute to their growth and retention, including seniority benefits. Over 75% of these nodes have been active and collateralized for over two and half years. Furthermore, SYS, the native currency of Syscoin, has been in circulation since 2014 and is broadly distributed.

In summary, Syscoin is

  • modular
  • exceptionally secure
  • scalable
  • decentralized
  • flexible
  • economical
  • reliable

Projects that are considering Syscoin, or that have questions, can reach out to the community and teams.

+ \ No newline at end of file diff --git a/docs/tech/bitcoin-tech/index.html b/docs/tech/bitcoin-tech/index.html index f3b8d325..d629c94c 100644 --- a/docs/tech/bitcoin-tech/index.html +++ b/docs/tech/bitcoin-tech/index.html @@ -6,13 +6,13 @@ Bitcoin Technology | Syscoin Docs - +

Bitcoin Technology

Thanks to Syscoin's code base being around 90% in-line with Bitcoin's (and kept closely up-to-date), Syscoin can utilize even the most recent technologies that have been developed on Bitcoin. This applies to the Syscoin native chain, rather than the NEVM chain. You can read about two of these technologies below.

Taproot/Schnorr#

Taproot is an upgrade to Bitcoin that brought several new features: Taproot, Tapscript and Schnorr signatures. The upgrade benefits Bitcoin in a number of ways. It improves Bitcoin's scripting language to make upgrades simpler. It also reduces the size of data required to be stored on-chain and through this lowers the transaction costs for users. It also improves the privacy of transactions. As this upgrade benefits Bitcoin, due to Syscoin maintaining around 90% of the codebase of Bitcoin these benefits are also brought to Syscoin on its base chain (not the NEVM chain).

As more innovative technologies are developed for Bitcoin, Syscoin will be able to tap into these innovations and improve at the same time. Not only do these new developments apply to the SYS coin, but also to tokens operating on top of the base chain. This is another of the numerous benefits of building on top of the Syscoin technology stack.

- + \ No newline at end of file diff --git a/docs/tech/finality/index.html b/docs/tech/finality/index.html index 62b589ad..77fdd8d8 100644 --- a/docs/tech/finality/index.html +++ b/docs/tech/finality/index.html @@ -6,13 +6,13 @@ Finality | Syscoin Docs - +

Finality

Decentralized and Fault Tolerant

Finality is the affirmation that all well-formed blocks will not be revoked once committed to the blockchain. The chain is not subject to the risk of reorganization further back than the most recent block that achieved finality. On the Syscoin network, all nodes recognize finalized blocks as valid and accepted. Any nodes with chains that differ further back than the last chainlock are not accepted as valid peers on the network.

Syscoin’s finality uses chainlocks which are sourced from a multi-quorum consisting of 4 groups of 400 Sentry Nodes (1,600 total). These quorums are randomly selected among the entirety of Syscoin's network of Sentry Nodes (currently ~2,700 at time of documenting). Each quorum is reformed every few hours. 3 out of 4 quorums must agree on a block in order to establish a chainlock.

This mechanism provides a high probability of finality in a decentralized way, and fault tolerance is inherited from the underlying Nakamoto consensus.

Time to finality after blockBlocktimeResilience absent finalityMechanism
Syscoin~12.5 minutes (every 5 blocks)2.5 minutesNakamoto longest chain rulePoW + Quorums
Ethereum~14 minutes (~3 epochs)10 secondsNone. No finality = breaking eventPoS + Casper

Graceful degradation#

In the rare event that finality cannot be achieved on a block for any reason

  1. The network falls back to the longest chain rule of Nakamoto consensus which is always operational. This is a seamless and non-breaking event, unlike pure proof-of-stake systems, all of which break under the same scenario.
  2. Because data availability (PoDA) depends upon finality for safe pruning of the blob cache, PoDA will retain blobs indefinitely until the blob's on-chain proof is secured by finality across a sum of ~six hours.

Resistance#

This finality mechanism provides resistance to 51% and selfish mining attacks. Attackers must accomplish two expensive and challenging tasks to achieve a successful 51% attack: 1) Control greater than 50% of Bitcoin's hash power supplied to Syscoin, plus 2) Control a super-majority of Syscoin Sentry Nodes.

Chainlocks can be viewed from a fully synced node by using Syscoin Core RPC getchainlocks.

img

- + \ No newline at end of file diff --git a/docs/tech/merged-mining/index.html b/docs/tech/merged-mining/index.html index cd32b827..6e3eb501 100644 --- a/docs/tech/merged-mining/index.html +++ b/docs/tech/merged-mining/index.html @@ -6,13 +6,13 @@ Merged Mining | Syscoin Docs - +

Merged Mining

Also known as Auxiliary Proof-of-Work or simply AuxPoW, merged mining enables you to mine multiple blockchains at the same time without spending additional energy on mining. It is carbon-neutral as it re-uses the proof from work already performed. It could be seen as someone (the miner) entering a lottery of sorts. With merged-mining the miner can submit the same lottery ticket and numbers to different lotteries (merge-mined blockchains), increasing their rewards.

Merged mining was first presented by Satoshi Nakamoto in 2010, and was subsequently introduced to Bitcoin Core. It can be considered a Bitcoin primitive. See Bitcoin's Merged Mining Specification.

From our perspective, it will be proven over time to be a critical component for incentivizing a robust and decentralized Bitcoin network as BTC block rewards will continue to diminish. Without merged-mining, revenue from mining Bitcoin would eventually be limited to Bitcoin’s flat network fees.

Furthermore, merged mining enables Bitcoin’s hashrate to be extensible and support blockchains that offer important utility beyond the scope and best-purpose of the Bitcoin protocol itself.

Note: Blockchains that naively use merge-mined settlement are subject to the same vectors of PoW in general. A solution now exists to solve those challenges, and it comes in the form of a hybrid consensus system that provides decentralized Finality on top of merged-mining. Such a solution is present in Syscoin. Dig into Syscoin's Finality.

For more information or to set up your miner(s) to merge-mine Syscoin, refer to the Merged Mining Setup Guide.

- + \ No newline at end of file diff --git a/docs/tech/nevm/index.html b/docs/tech/nevm/index.html index f50c6c12..cdc6b280 100644 --- a/docs/tech/nevm/index.html +++ b/docs/tech/nevm/index.html @@ -6,13 +6,13 @@ NEVM Chain (EVM) | Syscoin Docs - +

NEVM Chain (EVM)

What are Virtual Machines?#

Ethereum pioneered the virtual machine, which is essentially a processing machine for Ethereum-based smart contracts. A smart contract can range from a basic ERC20 token to a more sophisticated piece of code that underpins a decentralized application in this context.

The Ethereum Virtual Machine (EVM) offers a layer of abstraction between the smart contract code and the Ethereum network’s machine that executes it. Most Ethereum smart contracts are written in Solidity, a programming language created by Dr. Gavin Wood, one of Ethereum’s founders. EVM will also provide support for eWasm (Ethereum WebAssembly) which will enable smart contracts to be coded in various languages including C, C++, and more, which can be trans compiled and executed.

The EVM does not directly execute code. Instead, the code is compiled into opcodes when a smart contract developer is ready to deploy it. Opcodes are a collection of 141 unique instructions that the EVM employs to carry out activities depending on the coded instructions in the smart contract.

Each opcode has a fixed gas cost; however, some may also have a dynamic gas cost. The computational effort required to perform any given transaction on the Ethereum network is measured in gas, which in turn is used to calculate transaction fees in combination with the current demands, i.e. “traffic”, on the Ethereum network.

Turing-completeness refers to a computer’s capacity to tackle every solvable issue. The EVM’s 141 opcodes, meant to calculate every situation, was meant to be Turing-complete in theory. On a practical level, however, the EVM isn’t truly Turing-complete since the amount of gas available limits every computation.

Importance of Virtual Machines#

EVM introduced the world to the concept of decentralized smart contracts and conditional transactions which Bitcoin was unable to provide. The conditions for these transactions (the smart contracts), and execution of them by EVM, elevated blockchain tech beyond the very limited use of monetary transactionality, or simple value transfer, to serve as a decentralized computer.

The EVM is not without flaws. The most glaring example of this for the Ethereum network is that, due to design, it is not scalable. This means that as demand grows the network is unable to consistently provide reasonable transaction costs and fulfilment time. Ethereum is pursuing a proof-of-stake security system with the aim of addressing this, but it comes at a great cost; proof-of-stake is inherently less secure, and less proven (academically and in the real world) than proof-of-work.

What is Syscoin’s Network-Enhanced Virtual Machine (NEVM)?#

Syscoin NEVM is designed to provide smart contracts and interoperability that can scale to smart cities and beyond, while remaining low-cost and performant, and providing robust decentralized settlements that are secured by Bitcoin’s own proof-of-work security model via merged-mining. Blockchain users and market participants will increasingly realize the importance of proven security, especially as the risks of sundry experimental security models “come home to roost”. Furthermore, once Ethereum shifts to proof-of-stake, other proof-of-stake computation platforms will move closer to becoming superfluous, while Syscoin’s security will continue to be relevant.

With NEVM, Syscoin will essentially combine the strongest elements of Bitcoin (security model, merge-mined hashrate potential, UTXO efficiency and compatibility with future UTXO advancements) with Ethereum (broad usefulness of generalized computation), into a single decentralized coordinated financial computation platform. Syscoin will also improve upon both aspects. For example, on the UTXO side, chainlocks will address Bitcoin’s long-standing “selfish mining” vulnerability and harden the network against reorg impact after a chain lock is established which usually takes up to a minute after each block. On the NEVM side, we will implement zero-knowledge proofs to offer scalability and trustless interoperability for Turing-complete smart contracts. The chainlock’s mechanism gives a finality guarantee which is the desired effect of sharding and proof-of-stake on Ethereum 2.0. With finality, we can achieve better constraints for usable roll-up designs such as optimistic roll-ups, which require a waiting period of two weeks on Ethereum mainnet and can be much less on Syscoin due to new finality guarantees that chainlocks provide. On Syscoin the contracts would only have to wait hours on such designs and with the use of zero-knowledge proofs in zkRollups these withdrawal delays can be eliminated entirely.

Advantages of NEVM#

  • Smart contracts can scale to an arbitrary number of transactions using a blockchain that provides concise proofs of one-time executions which can be validated in parallel, instead of re-executing them.
  • A decentralized cost model that leads to a significantly more efficient market for gas fees
  • Sublinear, reliable, fault-tolerant blockchain with interactive data availability
  • Trustless cross-chain interoperability is generalized for easy integration with various blockchains, in a way that provides far less cost and technical overhead compared to SysEthereum v1.
  • A coordinated platform with optimal features for easy value transfer, store-of-value, and generalized computing, while retaining concern separation and scalability
  • The security of merged-mining the most reliable PoW network, tapping into most significant hashrate resource available: Bitcoin
  • Finality guarantee through chainlocks, which is based on the security of validators holding some amount of coins mined via PoW and participating in a supermajority of consensus on the current chain tip. This is free from the shortcomings of Proof-Of-Stake and especially the “nothing-at-stake”, which involves validators that are providing consensus without the backing of real sunk costs (energy, infrastructure). In the event a supermajority is not established, the chainlock mechanism resolves back down to a regular bitcoin-type policy.
- + \ No newline at end of file diff --git a/docs/tech/notary/index.html b/docs/tech/notary/index.html index 9903e1f0..c003c966 100644 --- a/docs/tech/notary/index.html +++ b/docs/tech/notary/index.html @@ -6,7 +6,7 @@ Notary and Business Rulesets | Syscoin Docs - + @@ -18,7 +18,7 @@ API endpoint URL.

When a client executes assetallocationsend, an HTTP POST is sent to the endpoint specified here and the client awaits a response. Response timeout is 15 seconds.

The client's POST provides the endpoint a raw transaction hex which the notary then decodes, parses, then logically processes.

The endpoint URL can point to any application or script of any language that can receive and process POST requests and provide an appropriate JSON response. The endpoint must return details of a successfully notarized (signed) transaction broadcasted to the network or the client's request is considered failed or rejected.

Endpoint programs can interact with Syscoin by making RPC calls directly to a Syscoin Core instance (see syscoin-js), or through a Web3 approach by using a combination of syscoinjs-lib and Syscoin Blockbook.

A rudimentary example of a notary endpoint is available here.

notary_details.instant_transfers (boolean) This flag indicates whether the notary is offering a guarantee of extra security in prevention of double spends. Recipients can instantly redeem/spend notarized inputs if they fully trust the notary's security.

This security path theoretically can provide payment service even faster than Z-DAG's decentralized relay and is based on an optional trust trade-off.

Endpoints can ensure protection against double spends by tracking spend requests of an input and responding to them based on the existence (or lack) of prior spend attempts.

If 0, the notary is not guaranteeing any supplementary security measures and transactors of the asset should rely exclusively upon Z-DAG and/or Syscoin Core consensus.

notary_details.hd_required (boolean) This flag indicates the notary requires HD wallet approval (for sender approval specifically applicable to change address schemes), usually in the form of the account XPUB or verifiable credential of the account XPUB using decentralized identity

How to Activate Notary#

An issuer can enable Notary on an asset by setting parameters in assetnew (upon asset creation), or assetupdate (updating the asset spec, if the asset's current update_capabilityflags value permits this).

Enable Notary via assetnew

> syscoin-cli assetnew 100 "ECASH" "Non-custodial KYC/AML-enabled Electronic Cash" "" 8 888000000 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://111.111.111.111:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {}

Enable Notary via assetupdate

> syscoin-cli assetupdate 1020176632 "Non-custodial KYC/AML-enabled Electronic Cash" "" 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://111.111.111.111:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {}
- + \ No newline at end of file diff --git a/docs/tech/poda/index.html b/docs/tech/poda/index.html index a22fd682..6d133eb0 100644 --- a/docs/tech/poda/index.html +++ b/docs/tech/poda/index.html @@ -6,12 +6,12 @@ BitcoinDA (Data Availability on Layer 1) | Syscoin Docs - +
-

BitcoinDA (Data Availability on Layer 1)

Overview#

Data availability is required to exist within the security domain of Layer 1 in order for rollups to properly serve critical financial applications by securing users’ ability to exit to L1. Syscoin’s L1 DA solution is called PoDA (Proof of Data Availability). Syscoin’s PoDA differs from Ethereum’s danksharding in how data is stored, presented, pruned, and how fees are calculated. PoDA has characteristics that make it a valuable alternative to Ethereum’s work-in-progress data availability solution, Proto-Danksharding.

BitcoinDA’s advantages can be summarized as:

  • Cheaper transactions
  • No data sharding required
  • Greater data throughput with efficient Keccak data blobs
  • Secured by Bitcoin’s own PoW plus Syscoin's finality
  • More resilient to network-based outages/censorship
  • Simpler data fee market based on Syscoin’s UTXO fee market
  • Nakamoto Assumption: Only one honest node is needed to guarantee data

BitcoinDA's design is based on PoDA (proof of data availability), which is a separation of concerns between data availability and data archiving with the protocol's purpose being the former.

info

Purpose of BitcoinDA

  • Deterministically ensure and prove that data has been placed within the commons and that the public was given a sufficient and defined opportunity to archive it.
  • Provide an on-chain hash necessary to verify the integrity of any archived data at a later time, and the option of custom hashes for other purposes a user might implement on top.

With BitcoinDA, by default, a Keccak256 hash of the full data blob is stored on Layer 1, while an assumption is made that at least one honest party in the world will archive the blob within at least a six-hour window of time - similar to the honesty assumption made when syncing a Bitcoin node (at least one honest node). After this window of time, the blob is pruned from the network's cache while its hash remains on-chain.

Validium (fully offchain DA) is also available as an alternative to BitcoinDA for less-critical applications where the focus might be on even lower cost and higher throughput by trading-off Layer 1 data security. However, in the case of Syscoin PoDA, Layer 1 data security is quite affordable; archivers store full data off-chain while you gain the security of an on-chain hash.

img

Sample BitcoinDA transaction#

This transaction was submitted by Rollux L2 to the Syscoin Native (UTXO) Mainnet.
+

BitcoinDA (Data Availability on Layer 1)

Overview#

Data availability is required to exist within the security domain of Layer 1 in order for rollups to properly serve critical financial applications by securing users’ ability to exit to L1. Syscoin’s L1 DA solution is called BitcoinDA. BitcoinDA differs from Ethereum’s Proto-Danksharding, and Celestia, in how data is stored, presented, pruned, and how fees are calculated. BitcoinDA provides characteristics that make it a valuable alternative to Ethereum’s work-in-progress data availability solution, Proto-Danksharding.

BitcoinDA’s advantages can be summarized as:

  • Cheaper transactions
  • No data sharding required
  • Greater data throughput with efficient Keccak data blobs
  • Secured by Bitcoin’s own PoW plus Syscoin's finality
  • More resilient to network-based outages/censorship
  • Simpler data fee market based on Syscoin’s UTXO fee market
  • Nakamoto Assumption: Only one honest node is needed to guarantee data

BitcoinDA's design is based on Syscoin's original PoDA (proof of data availability), which is a separation of concerns between data availability and data archiving with the protocol's purpose being the former.

info

Purpose of BitcoinDA

  • Deterministically ensure and prove that data has been placed within the commons and that the public was given a sufficient and defined opportunity to archive it.
  • Provide an on-chain hash necessary to verify the integrity of any archived data at a later time, and the option of custom hashes for other purposes a user might implement on top.

With BitcoinDA, by default, a Keccak256 hash of the full data blob is stored on Layer 1, while an assumption is made that at least one honest party in the world will archive the blob within at least a six-hour window of time - similar to the honesty assumption made when syncing a Bitcoin node (at least one honest node). After this window of time, the blob is pruned from the network's cache while its hash remains on-chain.

Validium (fully offchain DA) is also available as an alternative to BitcoinDA for less-critical applications where the focus might be on even lower cost and higher throughput by trading-off Layer 1 data security. However, in the case of Syscoin PoDA, Layer 1 data security is quite affordable; archivers store full data off-chain while you gain the security of an on-chain hash.

img

Sample BitcoinDA transaction#

This transaction was submitted by Rollux L2 to the Syscoin Native (UTXO) Mainnet.
https://blockbook.syscoin.org/tx/8de8bf84a1c55a06ad2d10ee10e036e51d122d02ded0a57ebddfd1da640aebc6

Note: The version hash is visible in the raw transaction data as scriptPubKey.asm: “OP_RETURN 20e76700ef2ceab4e1f71af30a1fcf0662eedbb932aa66285ac30dbca46256e7d4”

The hash of the data blob is stored on-chain as seen above in boldened portion of the sample's OP_RETURN. This should be used to prove the integrity of archived data at any future time.

How to interact with BitcoinDA#

Syscoin Core (>=v4.4) provides an RPC interface that enables use of the BitcoinDA protocol

Once submitted, the transaction with version hash is stored onchain in the next available block, while the full data blob is made publicly available within the native chain’s cache for a period of six hours of finality before being pruned. As long as the blob is cached, archiving services can access and store it. In the event that sufficient finality is absent, BitcoinDA will retain blobs in the cache until aforementioned finality threshold is met. This helps ensure published data is given proper guarantees to solve fisherman's dilemma even during adverse network conditions.

syscoincreatenevmblob#

Submit data blob with auto-generated Keccak256 versionHash (recommended)

syscoincreatenevmblob "data" ( overwrite_existing conf_target "estimate_mode" fee_rate )
Arguments:
1. data (string, required) blob in hex
2. overwrite_existing (boolean, optional, default=true) true to overwrite an existing blob if it exists, false to return versionhash of data on duplicate.
3. conf_target (numeric, optional, default=wallet -txconfirmtarget) Confirmation target in blocks
4. estimate_mode (string, optional, default="unset") The fee estimate mode, must be one of (case insensitive):
"unset"
"economical"
"conservative"
5. fee_rate (numeric or string, optional, default=not set, fall back to wallet fee estimation) Specify a fee rate in sat/vB.
Examples:
> syscoin-cli syscoincreatenevmblob "data"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "syscoincreatenevmblob", "params": ["data"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/
tip

You can extend the TTL (time-to-live) of a BitcoinDA blob for another six hours by resubmitting the same exact blob with the overwrite_existing flag set to TRUE.

syscoincreaterawnevmblob#

Submit data blob with custom (user-specified) versionHash. This might be useful if you wish to use a different hash algorithm or implement some custom commitment scheme as a layer on top of BitcoinDA. Otherwise, it is best to stick with the syscoincreatenevmblob standard.

syscoincreaterawnevmblob "versionhash" "data" ( conf_target "estimate_mode" fee_rate )
@@ -23,7 +23,7 @@
Arguments:
1. versionhash_or_txid (string, required) The version hash or txid of the NEVM blob
2. getdata (boolean, optional) Optional, retrieve the blob data
Examples:
> syscoin-cli getnevmblobdata
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getnevmblobdata", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8370/

How to run a BitcoinDA archive service#

As mentioned previously, with BitcoinDA the focus is DA. Archiving is left non-determined. However, tools are available.

Syscoin's Sentinel implementation provides the means to both store and retrieve BitcoinDA data blobs. Archivers may also employ other means at their discretion. If decentralized archiving is a priority, there are networks that can be custom-integrated with BitcoinDA, such a KYVE.

Syscoin Sentinel includes a BitcoinDA archive client/server with out-of-the-box support for Filecoin/Lighthouse and Cloudflare R2 (supply your API keys)
This is relatively easy to set up. Refer to the instructions on GitHub.

- + \ No newline at end of file diff --git a/docs/tech/rollux/index.html b/docs/tech/rollux/index.html index 03ce084f..f5772557 100644 --- a/docs/tech/rollux/index.html +++ b/docs/tech/rollux/index.html @@ -6,7 +6,7 @@ Rollux | Syscoin Docs - + @@ -26,7 +26,7 @@ PoDA: https://blockbook-dev.elint.services/tx/bae30de7850c370c77eb3590f631070d95c1a175323771fac5ab867fb1342136

Note: The Blockbook explorer does not currently parse the PoDA hash, but it is visible in the raw transaction data as scriptPubKey.asm: OP_RETURN 207f262f3352669030f480dd881bc6b3fad68abfcffe81d8e98c7f3e88871ed3a4

Q. How can I see/retrieve the full raw data blobs the L1 receives from the L2?
A. The hash of the raw data blob is always stored on-chain for the purpose of proving data integrity, as seen above in OP_RETURN. As for the full raw data blobs, they are available within the native chain’s mempool for a period of six hours before being pruned. During this window of time, archiving services can access and store the raw data. The data can be retrieved a couple of ways:

  • Syscoin Core RPCs: listnevmblobdata, getnevmblobdata
  • syscointx-js

Q. Are there any established processes for archiving Rollux raw data committed to PoDA?
A. Yes. Syscoin Sentinel provides a PoDA client and server that enables a Cloudflare R2 archive process to be activated relatively easily. This means any Syscoin Core node can provide data archive service that rollup solutions like Rollux can use. Refer to: https://github.com/syscoin/sentinel/blob/master/README.md

- + \ No newline at end of file diff --git a/docs/tech/sentrynodes/index.html b/docs/tech/sentrynodes/index.html index 605fa0bf..5e98b213 100644 --- a/docs/tech/sentrynodes/index.html +++ b/docs/tech/sentrynodes/index.html @@ -6,13 +6,13 @@ Sentry Nodes | Syscoin Docs - +

Sentry Nodes

This is a high level overview of Sentry Nodes, the roles they fulfill in our ecosystem, and their unique incentives.

note

Due to the sheer variety of specialized node-types in the world of blockchain technology (e.g. validators, various masternode types such as "guardians", etc.), it is important to explicitly state a few things that Sentry Nodes are not.

What Sentry Nodes Are Not#

  • A authoritative subset of nodes that other nodes or clients are forced to trust
  • A solution that resolves the tech stack down to Proof-of-Stake
  • Privacy providers
  • Block producers

The Roles of Sentry Nodes#

Beyond simply serving as incentivized full nodes, Sentry Nodes do fulfill a few roles unique to themselves.

Security Enhancement#

Sentry Nodes are Syscoin's solution to the challenge of providing a decentralized means of finality for Proof-of-Work (PoW) without resolving the entire stack down to sheer Proof-of-Stake (PoS). Sentry Nodes provide additive finality through multi-quorum chainlocks that resist 51% attacks and selfish mining. This turns merge-mining into a secure source of hashpower, and makes it possible for Syscoin to provide safe modular data availability while sticking to the Nakamoto ideal of every full node independently validating before trusting.

Finality is particularly important for securing modular ecosystems such as those supporting rollups, especially because proper data availability (DA) requires pruning, and pruning requires certain guarantees afforded only by finality. Lack of finality is the reason the Bitcoin chain itself cannot provide DA, and one of several reasons Syscoin's merge-mined chain is important for scaling and expanding Bitcoin in the most ideal way.

It is true that finality can be achieved relatively easily within the PoS model compared to PoW. However, Syscoin maintains that PoW (specifically Bitcoin's through merged mining) is most desireable for a settlement base-layer due to the hardness of PoW's real-world inputs, and its resilience against black swans such as wars and fiat hyper-inflationary events.

Ultimately we found the best finality would come in the form of an additive layer on top of standard Nakamoto-style consensus. In line with comments by Andreas Antonopoulos, we found that the quorums and chainlocks introduced by Dash in their evolution masternodes model would be useful to this end. However, some important changes and enhancements would be in order. Instead of Dash's single quorum, Syscoin implemented a more robust multi-quorum scheme, involved a greater portion of the network, and used a higher block time. Furthermore, the finality was made explicitly additive. In other words, in the rare event finality is not achieved, the chain continues unabated rather than having a breaking event.

Network Stability#

The great stability of Syscoin's network is due in large part to Sentry Nodes being incentivized with block rewards and seniority bonuses. At time of writing the vast majority of Sentry Nodes have been running for over 2.5 years, having reached maximum seniority. Our seniority model, which is unique, is a proven success in this regard.

Governance#

Syscoin's network of Sentry Node owners can participate in Syscoin's decentralized governance which takes place on a ~monthly basis. As a Sentry Node owner, you determine whether or not proposals get approved for superblock funding. Find out more and see how to participate in Syscoin's decentralized governance.

Incentives and Requirements#

Owning a Syscoin Sentry Node and providing this service to earn income requires you to hold 100,000 SYS as collateral. While the Sentry Node is active it will be paid regularly for its service. The beginning of payments is determined by when the Sentry Node goes online. The (deterministic) qualification period following a Sentry Node activation typically lasts around a week depending on how many Sentry Nodes are currently on the network. A newly activated Sentry Node is added to queue of those waiting to be paid each block and this position will be kept as long as it is live. Fewer Sentry Nodes on the network translates to more frequent payments. With ~2500 online, a Sentry Node receives income roughly once every three days.

The base income payment to a Sentry Node is a 52.91 SYS block reward as of January 2024. There are two further seniority levels based on when the 100,000 SYS collateral transaction was settled, as can be seen below.

Payouts as of January 2024

Seniority LevelBlock Payout
Basic52.91 sys
1 year71.43 sys
2.5 years105.83 sys

There is a 5% reduction in these payouts each year. This reduction will cease in the distant future at a minimum of 5.275 sys per payout for basic-seniority level nodes, and 10.55 sys for full-seniority nodes. This floor, combined with SYS EIP-1559 coinomics, serves to keep Sentry Nodes incentivized indefinitely into the future.

If you have 100,000 SYS and are interested in setting up a new Sentry Node, use this setup guide.

If you already have a Sentry Node and are looking to upgrade Syscoin Core to the current latest version (4.4), use this upgrade guide.

info

Sentry Node EVM Registry#

The Syscoin foundation provides an on-chain registry by which Sentry Node owners can provably associate an EVM address to their Sentry Node. This makes it technically possible for Sentry owners to receive exclusive airdrops, participate in external governance processes, and other perks within EVMs such as Rollux or Ethereum. If you own one or more Sentry Nodes, you should probably do this!

- + \ No newline at end of file diff --git a/docs/tech/tokens/index.html b/docs/tech/tokens/index.html index cfa3df6f..b6e559cf 100644 --- a/docs/tech/tokens/index.html +++ b/docs/tech/tokens/index.html @@ -6,13 +6,13 @@ Syscoin Platform Tokens (SPTs) | Syscoin Docs - +

Syscoin Platform Tokens (SPTs)

Syscoin Platform Tokens, or SPTs for short, are tokens that reside on the Syscoin Native (UTXO) blockchain, rather than the Syscoin NEVM blockchain that runs alongside it and supports ERC-20 tokens. SPTs are UTXO-based tokens (so transactions operate like Bitcoin transactions), rather than account-based (like Ethereum), this offers greater efficiency and allows SPTs to support any current or new innovations that are made available on Bitcoin, such as Lightning Network or Taproot. SPTs can also take advantage of Syscoin's Z-DAG technology, for blisteringly fast token payments. Find out how to create your own SPTs here.

Another useful aspect of SPTs is the possibility to create Non-Fungible Tokens (NFTs). These are very lightweight; compared to a standard, fungible token they use only 4 extra bytes on the blockchain. If you are interested in checking them out you can download Pali Wallet, a browser extension wallet that supports Syscoin and SPTs, and mint some NFTs on SysMint.

- + \ No newline at end of file diff --git a/docs/tech/z-dag/index.html b/docs/tech/z-dag/index.html index 6ba67c82..83d2237f 100644 --- a/docs/tech/z-dag/index.html +++ b/docs/tech/z-dag/index.html @@ -6,13 +6,13 @@ Z-DAG (UTXO) | Syscoin Docs - +

Z-DAG (UTXO)

Z-DAG White Paper (note: this paper does not reflect optimizations that came later)

Z-DAG is proprietary to Syscoin's native UTXO chain. It is not designed to function on Syscoin's EVM chain (NEVM).

Syscoin's Z-DAG is a blockchain throughput scalability solution that adds very little complexity. It solves problems endemic across the industry, not by altering mission-critical fundamentals or reinventing the wheel, but through proper tooling and facilitation across the network to maximize the utility of battle-tested Bitcoin code.

Z-DAG is based on Satoshi’s “snack machine” concept. It was invented by Syscoin Lead Core Developer Jag Sidhu to actualize peer-to-peer electronic cash and extend means-of-exchange to tokenized assets. It utilizes mempool awareness and fast relay topology across a network of independently operating full nodes (2k+ at present), all of which validate first, then trust. A high degree of probabilistic security is enabled by fast propagation across time-sorting mempools. This global mempool is made interactive and useful to the recipient through tooling that provides mempool status awareness.

The probabilistic security provided by Z-DAG represents a guarantee that a transaction is not double-spent, and will be accepted into a block and settled on-chain. The probability increases rapidly across time, to 99.9999% assurance within 10 seconds.

This enables a much more efficient fee market than bidding for a block. A typical Z-DAG transaction costs 0.0000582 SYS (see: https://syscoin.org/fees for a live fee comparison), and provides secure high-throughput service even if blocks are full. This is technically a layer-1 solution because the mempool resides within the blockchain security domain and all valid transactions that use Z-DAG settle on-chain through bitcoin-core-compliant consensus.

How is it useful?#

Syscoin’s implementation is particularly useful for microtransactions with tokens such as buying groceries with Binance USD, USDC, or simple value transfer of any token (this includes ERC-20s that use our bridge that is permissionless and trust-minimized). Z-DAG Protocol is utilized exclusively by the Syscoin token layer; all projects that tokenize on Syscoin benefit from this.

Z-DAG allows merchants or application developers to define their ideal speed/security trade-off particular to their use case, for example depending on the value involved. A merchant receiving payment for coffee might choose to wait only a few seconds before considering the payment safe against double-spends and redeemable. A cart full of groceries? Maybe 5 to 10 seconds. On the other hand, a nation-state settling a cross-border trade debt might wait for what they consider a sufficient number of confirmations (60 sec block target) on Syscoin's bitcoin-core-compliant and merge-mined blockchain.

Z-DAG is more ideal for payments than other scaling approaches that try to change the court-of-record (blockchain) consensus to force it to function as a payments service, ultimately tampering with proven security and creating severe trade-offs that are global.

Industry-proven decentralized consensus is valuable to enterprises. Our solution leaves the base layer intact. Syscoin Core is “religiously” maintained to remain bitcoin-core-compliant and up-to-date in a timely fashion (sometimes involving multiple commits in a single day), with 90%+ code coverage.

Throughput Performance#

Whiteblock Inc, a third-party auditor, provided performance benchmarks of Z-DAG within realistic network conditions, using hosts with standard Syscoin Sentry Node hardware specs. Whiteblock is well-known for its benchmark service and Genesis platform, particularly among the Ethereum community. The results for Z-DAG can be summarized as follows.

img

  • Parameters: network latency, quantity of nodes, quantity of assets.
  • Average throughput: 8k - 15k TPS depending on a range of latency
  • Burst throughput: 61k TPS (this rate can be sustained as long as the mempool is not full and latency conditions are conducive)
  • Zero-latency control group: 145K TPS (how most projects measure their TPS)

These represent some of the most positive throughput statistics in the industry for a decentralized ledger network. We plan to perform even more thorough testing once sufficient optimizations have been introduced. Substantial resources would be required to even approach pushing Z-DAG to its limit on the live mainnet.

Whiteblock's report on Z-DAG is public: Full Report, Summary Report

Scaling to Global Population Demand#

The Syscoin Team understands Z-DAG itself does not solve scalability for global population demand - the semi-absurd notion of 7 billion people transacting. Rather, we see it as an absolutely critical component to achieve this. The other component needed is multi-asset payment channels that use Z-DAG as a resilience fallback. One of the biggest problems with payment channels today is that when they aren't available (for any reason, e.g. lack of channel liquidity) the transactions roll directly to blockchain settlement. That destroys convenience and cost-savings, making payment channels non-viable as a decentralized payments solution compared to existing rails like centralized credit card networks.

Z-DAG fills this significant gap by providing a performant decentralized fallback with a reasonable and predictable fee-market. Syscoin and some academic partners like TU Delft are currently involved in R&D toward secure multi-asset payment channels - a technology which the industry has not yet achieved. We will combine this with Z-DAG.

- + \ No newline at end of file diff --git a/index_back/index.html b/index_back/index.html index 43a516e7..0bf7b255 100644 --- a/index_back/index.html +++ b/index_back/index.html @@ -6,13 +6,13 @@ Home Syscoin Docs | Syscoin Docs - +

Build the Future on Syscoin

Documentation for builders, futurists and revolutionaries

Developer Documentation

Developer Documentation

Deploy a NEVM Smart Contract

Deploy a NEVM Smart Contract

What is Syscoin?

What is Syscoin?

User Guides

User Guides

Get SYS

Get SYS

- + \ No newline at end of file