Cynigiodd Matt Corallo ychydig yn fwy nag wythnos yn ôl BIP ar gyfer cydlynu gwneud taliadau Bitcoin. Mae gwneud taliadau bitcoin bob amser wedi cyflwyno rhywbeth o her o ran cydlynu, ar y gadwyn ac oddi ar y gadwyn â phrotocolau fel Mellt, am wahanol resymau. O ran systemau digidol fel e-bost neu systemau talu fel Paypal, Cashapp, ac ati mae pobl yn gyfarwydd iawn â'r cysyniad o un dynodwr sefydlog. Os ydych chi am anfon e-bost at John, anfonwch e-bost at “john@[insert domain].” Os ydych chi am anfon rhywfaint o arian i John ar Cashapp, rydych chi'n anfon taliad at @John ar Cashapp.
Dyma brofiad y defnyddiwr y mae pobl yn gyfarwydd ag ef, ac o ran ymddygiad a disgwyliadau defnyddwyr sydd wedi hen ymwreiddio â phethau mae'n anhygoel o anodd eu gwthio i newid sylweddol neu sydyn yn eu hymddygiad. Os ydych chi'n cyflwyno offeryn iddynt sy'n gofyn am hynny, mae'n cyflwyno llawer iawn o ffrithiant ac yn fwy na thebyg yn mynd i atal y rhan fwyaf o bobl rhag defnyddio'r offeryn hwnnw.
Mae taliadau ar gadwyn yn dod yn broblem gyda’r disgwyliad hwn, nid oherwydd anallu i gael dynodwr statig (un cyfeiriad), ond oherwydd goblygiadau preifatrwydd postio un cyfeiriad ar-gadwyn a chael pawb yr ydych yn rhyngweithio â nhw i ddefnyddio hynny i dalu i chi. Mae'n rhoi eich hanes talu cyfan a pherchnogaeth darnau arian yng ngolwg y cyhoedd i bawb. Os mai anaml y byddwch chi'n derbyn arian yn awr ac yn y man, hy wrth gael eich talu am waith neu setlo tabiau bar gyda phobl, nid yw'n faich o gwbl agor eich waled a chynhyrchu cyfeiriad newydd i'w dderbyn. Fodd bynnag, os ydych yn derbyn arian yn aml, yn enwedig mewn achosion lle nad ydych yn gofyn yn uniongyrchol am y taliad, mae hynny'n faich difrifol.
Dyma pam y crëwyd offer fel Gweinyddwr BTCPay, er mwyn lleihau’r rhwystr i fynediad i bobl sbinio’r seilwaith angenrheidiol i awtomeiddio derbyn arian heb wneud rhywbeth naïf fel postio un cyfeiriad i bawb sy’n talu i chi ei ailddefnyddio. Fodd bynnag, mae hyn yn golygu bod angen rhedeg gweinydd sydd ar gael yn gyson ar-lein. Er bod y prosiect wedi gostwng yn sylweddol y bar o ddealltwriaeth sydd ei angen, mae'n dal i fod yn faich uchel i ddefnyddiwr sydd eisiau gallu derbyn arian yn oddefol.
Mae'r un peth yn wir am Mellt ac eithrio'n waeth. Dim ond ar gyfer un taliad y mae anfoneb yn dda. Yn wahanol i gyfeiriad ar gadwyn, y gellir ei ailddefnyddio er ei fod yn arfer erchyll, ni ellir defnyddio anfoneb Mellt. Unwaith y bydd yr anfoneb naill ai wedi'i thalu neu wedi dod i ben bydd y nod Mellt dan sylw yn gwadu unrhyw ymgais i'w thalu. Arweiniodd y deinamig hwn at greu'r fanyleb LNURL, yn ogystal â Chyfeiriadau Mellt a adeiladwyd ar ei ben. Mae LNURL yn brotocol ar gyfer cysylltu â gweinydd HTTP trwy IP statig y gellir ei rannu unwaith er mwyn cael anfoneb Mellt go iawn i'w thalu o'r gweinydd. Gan adeiladu ar hynny, mae Cyfeiriadau Mellt yn gynllun enwi ar ben LNURL sydd wedi'i strwythuro'n debyg i gyfeiriadau e-bost: John@[domain of LNURL server].
Mae anfanteision i bob un o'r atebion hyn. Y gofyniad i redeg darn ychwanegol o feddalwedd (gweinydd HTTP) sy'n aros ar-lein drwy'r amser yn ychwanegol at eich waled Bitcoin neu nod Mellt; mae gwneud cais i weinydd BTCPay/LNURL yn gollwng cyfeiriad IP yr anfonwr i'r derbynnydd; dibynnu ar Awdurdodau Tystysgrif TLS.
Dim ond Defnyddiwch DNS
Mae offer gweinydd HTTP fel LNURL wrth eu paru â Lightning Address yn defnyddio parthau i ddatrys y cysylltiad â'r gweinydd HTTP. Yn yr un modd mae Gweinyddwyr BTCPay i gyd wedi'u ffurfweddu gyda pharthau yn hytrach na defnyddio cyfeiriadau IP amrwd. Mewnwelediad Matt yw pam na wnewch chi dorri'r ddibyniaeth ar HTTP a defnyddio'r System Enw Parth ei hun?
Mae DNS yn caniatáu ichi gysylltu cofnodion TXT ag enw parth penodol, gan greu cofnodion darllenadwy bach dynol (neu beiriant) y gellir eu holi gan weinyddion DNS. Ar y cyd ag Estyniadau Diogelwch System Enw Parth (DNSSEC) mae cofnodion DNS TXT yn darparu mecanwaith y gellir ei ddefnyddio er mwyn cwestiynu gwybodaeth am daliadau heb y gorbenion a'r baich o redeg gweinydd HTTP, yn ogystal â chynnig ychydig mwy o hyblygrwydd a didwylledd. Mae DNSSEC yn darparu nifer o offer ar gyfer llofnodi cofnodion DNS yn cryptograffig, gan gynnwys cofnodion TXT, gyda'r allweddi DNS sy'n gynhenid yn strwythur hierarchaidd DNS. Mae hyn yn rhoi gwarant mai'r cofnod TXT rydych chi'n ei holi yw'r cofnod a lofnodwyd gan weinyddion DNS lefel is a'u dosbarthu i weinyddion DNS lefel is o'r gweinydd/allwedd gwraidd lleol.
Mae hyn yn dod i fudd gwirioneddol DNS fel modd o nôl data talu: ffarwelio â'r gofyniad o orfod rhedeg gweinydd HTTP. Gall cofnod TXT amgodio cyfeiriad Bitcoin ar gadwyn (er bod y BIP yn argymell yn benodol YN ERBYN gwneud hyn os nad ydych yn gallu cylchdroi cyfeiriadau newydd yn rheolaidd i atal ailddefnyddio cyfeiriadau), ond yn bwysicach fyth gall hefyd gynnwys Cynnig Mellt BOLT 12.
Gellir nôl y cofnodion hyn o unrhyw weinydd DNS, eich un lleol eich hun, eich ISP, hyd yn oed gweinydd cyhoeddus fel Google neu Cloudflare. O'r pwynt sylfaenol hwn, mae un diffyg o atebion seiliedig ar HTTP yn cael ei ddatrys; nid ydych bellach yn gollwng eich cyfeiriad IP i'r person rydych yn ceisio ei dalu. Nawr, yn achos defnyddio DNS eich ISP neu weinydd cyhoeddus fel Google neu Cloudflare heb VPN neu Tor rydych chi'n datgelu eich cyfeiriad IP iddynt; mae'r BIP yn amlwg yn annog cefnogaeth i ddatrysiad DNS dros VPN neu Tor am y rheswm hwn yn benodol.
Mae cyfuno'r cynnig hwn â BOLT 12 yn dileu'r angen am redeg meddalwedd ategol sy'n peri pryder diogelwch gwirioneddol i ddefnyddwyr ansoffistigedig, ac yn caniatáu perchnogaeth parth yn unig i roi popeth sydd ei angen ar ddefnyddwyr i gael mecanwaith i leoli gwybodaeth am daliadau gyda pherson syml. dynodwr darllenadwy. Nid yw BOLT 12 yn gofyn am unrhyw weinydd HTTP, sy'n trin y danfoniad anfoneb gwirioneddol dros gysylltiadau llwybr nionyn yn uniongyrchol trwy'r Rhwydwaith Mellt, ac mae'n cefnogi Offers, dynodwr statig y gellir ei ddefnyddio i ddod o hyd i lwybr nionyn i'r nod Mellt hwnnw. Y broblem yw bod y Cynnig wedi’i amgodio fel llinyn anferth sy’n edrych ar hap fel anfoneb ei hun, sy’n ei wneud yn ddynodwr ofnadwy y gellir ei ddarllen/defnyddio gan ddyn ac eithrio trwy ddefnyddio codau QR neu gopïo a gludo.
Trwy storio Cynnig mewn cofnod DNS TXT, y cyfan sydd ei angen ar ddefnyddiwr er mwyn gwneud taliad yw parth rhywun i'w deipio i'w waled fel y gall nôl y cofnod TXT, nôl y Cynnig BOLT 12, ac yna gwneud y taliad. Nid oes angen iddynt gynnal unrhyw weinydd na rhedeg unrhyw feddalwedd heblaw eu nod Mellt, mae'r system DNS yn trin popeth ar eu cyfer cyn belled â chynnal eu BOLT 12 Cynnig rhywun y gall defnyddwyr sydd am eu talu ddod o hyd iddynt.
A yw hon yn system gwbl ddi-ymddiried? Na. A yw'n llawer gwell na systemau sy'n seiliedig ar HTTP? Yn hollol. Y broblem gyda materion fel hyn yw bod yna ddisgwyliad penodol o UX ac ymddygiad sydd gan y rhan fwyaf o bobl cyn belled ag y mae systemau digidol i fod i weithio yn eu meddyliau. Heb ailadrodd yr UX hwnnw, bydd grwpiau mawr o bobl yn defnyddio dewisiadau eraill sy'n bodloni'r disgwyliad UX hwnnw. O ystyried y realiti hwnnw, wrth geisio ffitio Bitcoin i mewn i flwch y disgwyliadau UX hynny, y nod dylunio ddylai fod i ddiwallu anghenion y defnyddwyr hynny gyda'r ychydig iawn o ymddiriedaeth a ymyrraeth, y swm lleiaf o faich a roddir ar y defnyddwyr, a'r potensial lleiaf posibl ar gyfer colli preifatrwydd mewn ffyrdd newydd. Rwy'n meddwl bod BIP Matt yn gwirio pob un o'r blychau hynny o gymharu â datrysiadau presennol.
Ffynhonnell: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments