Erik Aronesty [ARCHIVE] on Nostr: đź“… Original date posted:2021-06-19 đź“ť Original message:There is no solution to ...
đź“… Original date posted:2021-06-19
đź“ť Original message:There is no solution to preventing the fraud proofs. This is a known issue
for Bitcoin in general. It basically caps your protocol at the cost of
performing a fraud proof attack.
Also I would ditch email in the core protocol, and use QR codes and
device-to-device linking.
client a shows QR
client b scans QR (which is a pubkey)
client b publishes his pubkey (gossip network), with POSK proof
Then you add to your contact list.
Email to be an optional clearly less secure layer but not part of the core
protocol. It is vulnerable to mitm (how do you know who you're paying),
but again for small values and known risks it's not terrible.
On Fri, Jun 18, 2021 at 4:00 PM <raymo at riseup.net> wrote:
>
>
> Hi Alex,
>
> The 10 Sat fee is Sabu-transaction-fee and goes to issuers to
> incentivize UTXO owners to put their money in system and prepare money
> transfer service for the Creditors. pretty much like banks.
> This number is my suggestion, but can be changed to something higher or
> lesser or even being customized for each issuer(Banks with high fee and
> more speed/reliability or less fee and less speed but more distributed).
>
> Typically Issuers put an UTXOs worth 40,000 Sat and issue a
> debt-document(transaction) worth 20,000 or less. So issuer can use
> thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document
> (worth 20,000,000 debit) and earn significant Sabu-transaction-fee
> daily.
> No need to say the issuer also dictates the fiat to BTC exchange rate in
> first step, and can earn even more benefits by selling BTC a little
> higher than market price. The target would be penny savers which
> potentially buy very small amount each time(teenagers or people with low
> income specially).
>
> About your double-spend scenario please write a clear scenario and use
> the conventional terms such as issuer, creditor, MT, GT, CT etc... to
> study its feasibility. Maybe there are corner cases which I missed. So
> we will fix it as well.
>
> About p2p Gossiping, you are right. There is latency but it doesn't hurt
> the consensus on Sabu protocol. Please consider figure 7. inter
> creditors Bitcoin transfer as an example. By the way in all money
> transactions between issuer -> creditor or creditor->creditor, the
> receiver wallet "always" controls the doc-watcher client to be ensure
> the fact that the delivered debt-document(aka transaction) to receiver
> wallet, already exist on the doc-watcher sites. If that particular
> document exist in doc-watcher , the wallet consider it as a valid
> transaction, otherwise creditor won't accept the deal as a settled deal.
>
> >I think you will end up reinventing a lot of the problems solved by
bitcoin.
>
> No, that's not true. Because I proposed a complementary tool for Bitcoin
> which came from a different point of view. Note the fact that Sabu
> protocol realizes a different model of decentralization. In Sabu there
> is no DLT at all and all consensus are between small set of users (most
> of time between an issuer and a creditor). In Sabu there is no
> obligation for everyone know everything about every transaction. Each
> participant only knows about its interest. Alongside there is a gossip
> mirroring of all transaction that flood to the clients a light weight
> information of a tuple [UTXO, transaction-Merkle-root]. These gossip
> nodes (doc-watchers) are not corruptible since it works in a simple
> proof-of-existance (true-positive) model. And no one can mutilate it by
> censor transactions.
>
> >Why did you pick email as the RPC mechanism to transfer these notes?
>
> First of all I have to explain a part of design spec. Each mobile wallet
> has to have a fresh email address which is dedicated to Sabu protocol
> activities. The wallet has access to this email address and read, delete
> inbox or send emails. So the spam or spam filter problem is not the
> case.
>
> In my opinion email is the ONLY neutral, free (non proprietary) and open
> protocol/technology for communication in the world that its
> infrastructure is well-established and is accessible all over the glob.
> Even in countries with low internet speed.
> I intentionally chose email as main communication mean. Because non
> technical people can easily make an email address or change it
> (comparing establish a website or use an static IP) and notify the
> friends about new address and they can easily send and receive Bitcoin
> just by knowing email addresses. Once the user install the
> Sabu-supporter-wallet (called Gazin), he will config and record his 12
> seed words. The wallet also creates the PGP Pub/Priv key pair based on
> these 12 words seeds and signs the wallet email address too. All are
> take place behind the scene and user only sees its wallet is ready. So
> these 12 worlds are users wealth protector and identity sovereignty as
> well. User adds friends wallet email address or scan its QR code. The
> rest is PGP encrypted emails(handshake, agreement and transactions)
> between two wallets. No one needs to ask a central service to have an
> account. Pure Cypher punk users can run their personal email server or
> even better their freedombox https://freedomboxfoundation.org. So no one
> can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his
> account. The wallet owner can easily and fast immigrate to new email
> address (or even different email service provider) and sign new address
> and notify to his friends circle with no real barrier.
> While these are all benefits of using email as a user identifier in
> system, there could be some privacy issue in some levels. For example
> most email service provider impose some sort of KYC or ask user mobile
> number, but there are other providers which are respecting users
> privacy. implicitly prevalence of Sabu users creates more demands for
> this privacy-respector-companies, so these companies will be increased.
> Another issue would be global passive spying or full-pipe project will
> find who do transaction with who. Since communications are PGP encrypted
> it won't be clear who is sender or receiver or how much is transferred
> or even if they are really parties in a transaction or it is just a fake
> noise connection! The forward secrecy also would be another issues.
> although these are mostly the privacy issues rather than Sabu intrinsic
> problems.
> Some other disadvantage of email is latency, so some third parties would
> easily provide the optional alternate communication services for wallet,
> e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to
> compensate the speed and/or privacy issues. These are all communication
> means and the wallet can simply use one or more methods in parallel.
> Later we will see the wallet users will choose which solution. Speed vs
> privacy, sovereignty and independence.
>
> Regards
> Raymo
>
> On 2021-06-18 13:44, Alex Schoof wrote:
> > A few questions/comments:
> >
> > Why is there a 10 sat fee on each tx? Where does that fee go?
> >
> > I don’t think this design sufficiently protects against double
> > spends by the “issuer” (the person who actually has the UTXO).
> > Your guarantee tx mechanism only really covers the case where someone
> > tries to double spend part of a UTXO balance (in other words, if the
> > penalty lost is less than the value gained by doing a double spend,
> > its worth it to double spend, and in a world where you’re passing
> > around digital IOUs, it’s easy to make it worth it). Later in the
> > post, you mention that there will be a p2p network to gossip fund
> > transfers and that will prevent an issuer from double spending. The
> > problem there is that network latency is non-zero, large network
> > partitions are both real and common, and nodes can come and go anytime
> > (hardware failure, power failure, network partition healing, just
> > because they feel like it, etc). Different nodes on the network might
> > hear about different, conflicting transactions. Nodes will need a way
> > to all come to consensus on what the right set of “sent notes” is.
> > I think you will end up reinventing a lot of the problems solved by
> > bitcoin.
> >
> > Why did you pick email as the RPC mechanism to transfer these notes?
> > Email is going to add variable amounts of latency and things like spam
> > filters will cause issues.
> >
> > Alex
> >
> > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> for very small transactions, this seems to make a hell of a lot of
> >> sense.
> >>
> >> it's like lightning, but with no limits, no routing protocols...
> >> everything is guaranteed by relative fees and the cost-of-theft.
> >>
> >> pretty cool.
> >>
> >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Hi,
> >>> I have a proposal for improve Bitcoin TPS and privacy, here is the
> >> post.
> >>>
> >>
> >
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> >>> https://bitcointalk.org/index.php?topic=5344020.0
> >>> Can you please read it and share your idea about it.
> >>>
> >>> Cheers
> >>> Raymo
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > --
> >
> > Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210619/263261f6/attachment-0001.html>;
đź“ť Original message:There is no solution to preventing the fraud proofs. This is a known issue
for Bitcoin in general. It basically caps your protocol at the cost of
performing a fraud proof attack.
Also I would ditch email in the core protocol, and use QR codes and
device-to-device linking.
client a shows QR
client b scans QR (which is a pubkey)
client b publishes his pubkey (gossip network), with POSK proof
Then you add to your contact list.
Email to be an optional clearly less secure layer but not part of the core
protocol. It is vulnerable to mitm (how do you know who you're paying),
but again for small values and known risks it's not terrible.
On Fri, Jun 18, 2021 at 4:00 PM <raymo at riseup.net> wrote:
>
>
> Hi Alex,
>
> The 10 Sat fee is Sabu-transaction-fee and goes to issuers to
> incentivize UTXO owners to put their money in system and prepare money
> transfer service for the Creditors. pretty much like banks.
> This number is my suggestion, but can be changed to something higher or
> lesser or even being customized for each issuer(Banks with high fee and
> more speed/reliability or less fee and less speed but more distributed).
>
> Typically Issuers put an UTXOs worth 40,000 Sat and issue a
> debt-document(transaction) worth 20,000 or less. So issuer can use
> thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document
> (worth 20,000,000 debit) and earn significant Sabu-transaction-fee
> daily.
> No need to say the issuer also dictates the fiat to BTC exchange rate in
> first step, and can earn even more benefits by selling BTC a little
> higher than market price. The target would be penny savers which
> potentially buy very small amount each time(teenagers or people with low
> income specially).
>
> About your double-spend scenario please write a clear scenario and use
> the conventional terms such as issuer, creditor, MT, GT, CT etc... to
> study its feasibility. Maybe there are corner cases which I missed. So
> we will fix it as well.
>
> About p2p Gossiping, you are right. There is latency but it doesn't hurt
> the consensus on Sabu protocol. Please consider figure 7. inter
> creditors Bitcoin transfer as an example. By the way in all money
> transactions between issuer -> creditor or creditor->creditor, the
> receiver wallet "always" controls the doc-watcher client to be ensure
> the fact that the delivered debt-document(aka transaction) to receiver
> wallet, already exist on the doc-watcher sites. If that particular
> document exist in doc-watcher , the wallet consider it as a valid
> transaction, otherwise creditor won't accept the deal as a settled deal.
>
> >I think you will end up reinventing a lot of the problems solved by
bitcoin.
>
> No, that's not true. Because I proposed a complementary tool for Bitcoin
> which came from a different point of view. Note the fact that Sabu
> protocol realizes a different model of decentralization. In Sabu there
> is no DLT at all and all consensus are between small set of users (most
> of time between an issuer and a creditor). In Sabu there is no
> obligation for everyone know everything about every transaction. Each
> participant only knows about its interest. Alongside there is a gossip
> mirroring of all transaction that flood to the clients a light weight
> information of a tuple [UTXO, transaction-Merkle-root]. These gossip
> nodes (doc-watchers) are not corruptible since it works in a simple
> proof-of-existance (true-positive) model. And no one can mutilate it by
> censor transactions.
>
> >Why did you pick email as the RPC mechanism to transfer these notes?
>
> First of all I have to explain a part of design spec. Each mobile wallet
> has to have a fresh email address which is dedicated to Sabu protocol
> activities. The wallet has access to this email address and read, delete
> inbox or send emails. So the spam or spam filter problem is not the
> case.
>
> In my opinion email is the ONLY neutral, free (non proprietary) and open
> protocol/technology for communication in the world that its
> infrastructure is well-established and is accessible all over the glob.
> Even in countries with low internet speed.
> I intentionally chose email as main communication mean. Because non
> technical people can easily make an email address or change it
> (comparing establish a website or use an static IP) and notify the
> friends about new address and they can easily send and receive Bitcoin
> just by knowing email addresses. Once the user install the
> Sabu-supporter-wallet (called Gazin), he will config and record his 12
> seed words. The wallet also creates the PGP Pub/Priv key pair based on
> these 12 words seeds and signs the wallet email address too. All are
> take place behind the scene and user only sees its wallet is ready. So
> these 12 worlds are users wealth protector and identity sovereignty as
> well. User adds friends wallet email address or scan its QR code. The
> rest is PGP encrypted emails(handshake, agreement and transactions)
> between two wallets. No one needs to ask a central service to have an
> account. Pure Cypher punk users can run their personal email server or
> even better their freedombox https://freedomboxfoundation.org. So no one
> can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his
> account. The wallet owner can easily and fast immigrate to new email
> address (or even different email service provider) and sign new address
> and notify to his friends circle with no real barrier.
> While these are all benefits of using email as a user identifier in
> system, there could be some privacy issue in some levels. For example
> most email service provider impose some sort of KYC or ask user mobile
> number, but there are other providers which are respecting users
> privacy. implicitly prevalence of Sabu users creates more demands for
> this privacy-respector-companies, so these companies will be increased.
> Another issue would be global passive spying or full-pipe project will
> find who do transaction with who. Since communications are PGP encrypted
> it won't be clear who is sender or receiver or how much is transferred
> or even if they are really parties in a transaction or it is just a fake
> noise connection! The forward secrecy also would be another issues.
> although these are mostly the privacy issues rather than Sabu intrinsic
> problems.
> Some other disadvantage of email is latency, so some third parties would
> easily provide the optional alternate communication services for wallet,
> e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to
> compensate the speed and/or privacy issues. These are all communication
> means and the wallet can simply use one or more methods in parallel.
> Later we will see the wallet users will choose which solution. Speed vs
> privacy, sovereignty and independence.
>
> Regards
> Raymo
>
> On 2021-06-18 13:44, Alex Schoof wrote:
> > A few questions/comments:
> >
> > Why is there a 10 sat fee on each tx? Where does that fee go?
> >
> > I don’t think this design sufficiently protects against double
> > spends by the “issuer” (the person who actually has the UTXO).
> > Your guarantee tx mechanism only really covers the case where someone
> > tries to double spend part of a UTXO balance (in other words, if the
> > penalty lost is less than the value gained by doing a double spend,
> > its worth it to double spend, and in a world where you’re passing
> > around digital IOUs, it’s easy to make it worth it). Later in the
> > post, you mention that there will be a p2p network to gossip fund
> > transfers and that will prevent an issuer from double spending. The
> > problem there is that network latency is non-zero, large network
> > partitions are both real and common, and nodes can come and go anytime
> > (hardware failure, power failure, network partition healing, just
> > because they feel like it, etc). Different nodes on the network might
> > hear about different, conflicting transactions. Nodes will need a way
> > to all come to consensus on what the right set of “sent notes” is.
> > I think you will end up reinventing a lot of the problems solved by
> > bitcoin.
> >
> > Why did you pick email as the RPC mechanism to transfer these notes?
> > Email is going to add variable amounts of latency and things like spam
> > filters will cause issues.
> >
> > Alex
> >
> > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> for very small transactions, this seems to make a hell of a lot of
> >> sense.
> >>
> >> it's like lightning, but with no limits, no routing protocols...
> >> everything is guaranteed by relative fees and the cost-of-theft.
> >>
> >> pretty cool.
> >>
> >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Hi,
> >>> I have a proposal for improve Bitcoin TPS and privacy, here is the
> >> post.
> >>>
> >>
> >
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> >>> https://bitcointalk.org/index.php?topic=5344020.0
> >>> Can you please read it and share your idea about it.
> >>>
> >>> Cheers
> >>> Raymo
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > --
> >
> > Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210619/263261f6/attachment-0001.html>;