* [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
@ 2021-06-16 13:44 raymo
2021-06-18 1:42 ` Erik Aronesty
` (3 more replies)
0 siblings, 4 replies; 41+ messages in thread
From: raymo @ 2021-06-16 13:44 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
@ 2021-06-18 1:42 ` Erik Aronesty
2021-06-18 13:44 ` Alex Schoof
2021-06-18 13:37 ` Erik Aronesty
` (2 subsequent siblings)
3 siblings, 1 reply; 41+ messages in thread
From: Erik Aronesty @ 2021-06-18 1:42 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
2021-06-18 1:42 ` Erik Aronesty
@ 2021-06-18 13:37 ` Erik Aronesty
2021-06-18 20:22 ` raymo
2021-06-20 0:53 ` ZmnSCPxj
2021-06-20 1:59 ` James Hilliard
3 siblings, 1 reply; 41+ messages in thread
From: Erik Aronesty @ 2021-06-18 13:37 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
It is vulnerable to sybil attacks or where the recipient is a victim of a
proxy attack. If the recipient is not connected to a valid Network, then
double spends could be allowed.
as long as this protocol is intended for use of transactions around a
dollar or so I don't see that being a financially lucrative attack.
However consider a large department store. If I put a "fence" around that
store and control all of its outbound peer connections, I can then allow
double spends for the duration of my visit at the store.
In order to defend against this large retailers would have to use
distributed / trusted nodes and certificates.
On Thu, Jun 17, 2021, 4:14 PM raymo via bitcoin-dev <
bitcoin-dev@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2489 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-18 1:42 ` Erik Aronesty
@ 2021-06-18 13:44 ` Alex Schoof
2021-06-18 20:00 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Alex Schoof @ 2021-06-18 13:44 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Erik Aronesty
[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]
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@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@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@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
[-- Attachment #2: Type: text/html, Size: 3962 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-18 13:44 ` Alex Schoof
@ 2021-06-18 20:00 ` raymo
2021-06-19 21:14 ` Erik Aronesty
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-18 20:00 UTC (permalink / raw)
To: Alex Schoof; +Cc: Bitcoin Protocol Discussion
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@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@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> --
>
> Alex Schoof
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-18 13:37 ` Erik Aronesty
@ 2021-06-18 20:22 ` raymo
0 siblings, 0 replies; 41+ messages in thread
From: raymo @ 2021-06-18 20:22 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
I think I respond to sybil attack implicitly in Max response. Since the
only consensus must be between issuer and creditor and they already are
in a kind of web of trust connection.
By the way it would be great if you explain the attack scenario in more
detail and our conventional terms such as issuer, creditor, MT, GT, CT,
etc...
definitely we can solve it as well.
On 2021-06-18 13:37, Erik Aronesty wrote:
> It is vulnerable to sybil attacks or where the recipient is a victim
> of a proxy attack. If the recipient is not connected to a valid
> Network, then double spends could be allowed.
>
> as long as this protocol is intended for use of transactions around a
> dollar or so I don't see that being a financially lucrative attack.
>
> However consider a large department store. If I put a "fence" around
> that store and control all of its outbound peer connections, I can
> then allow double spends for the duration of my visit at the store.
>
> In order to defend against this large retailers would have to use
> distributed / trusted nodes and certificates.
>
> On Thu, Jun 17, 2021, 4:14 PM raymo via bitcoin-dev
> <bitcoin-dev@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-18 20:00 ` raymo
@ 2021-06-19 21:14 ` Erik Aronesty
0 siblings, 0 replies; 41+ messages in thread
From: Erik Aronesty @ 2021-06-19 21:14 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9879 bytes --]
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@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@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@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@lists•linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > --
> >
> > Alex Schoof
[-- Attachment #2: Type: text/html, Size: 12832 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
2021-06-18 1:42 ` Erik Aronesty
2021-06-18 13:37 ` Erik Aronesty
@ 2021-06-20 0:53 ` ZmnSCPxj
2021-06-26 21:54 ` raymo
2021-06-20 1:59 ` James Hilliard
3 siblings, 1 reply; 41+ messages in thread
From: ZmnSCPxj @ 2021-06-20 0:53 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
Good morning Raymo,
> 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.
Guarantee Transactions (GT) being higher-fee is ***not*** assured.
Feerates are always bumpable --- the sender of a transaction only needs to directly contact a miner and offer a fee to take a specific transaction on the next block proposal, conditional on the transaction *actually* getting into a block.
Such "side fees" are always possible.
Indeed, the in-transaction fees are "just" a way to anonymously and atomically make that fee offer to miners --- but miners and issuers can always communicate directly without using Bitcoin transaction to arrange a higher fee for a fraudulent Main Transaction (MT).
because of this, you should really treat all unconfirmed transactions --- including MTs and GTs --- as potentially replaceable, i.e. RBFable.
There is no such thing as "RBF disabled", all transactions are inherently RBF-able due to side fees --- it is simply a matter of anonymity, atomicity, and ease-of-use.
---
Every offchain protocol needs *the receiver* as a signatory to any unconfirmed transaction.
Or more strongly, the receiver **must** be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does *not* have the receiver as a signatory.
See: https://zmnscpxj.github.io/offchain/safety.html
Thus, all safe offchain schemes need to use an n-of-n signing set.
The smallest n-of-n that is still useful is 2-of-2, where one participant is a sender and the other is a receiver.
(1-of-1 is not useful since there is no possible receiver who can sign).
This requires Bitcoin to splinter into lots of 2-of-2 funds, each one a sovereign sub-money (that is *eventually* convertible to Bitcoin), each one a cryptocurrency system in its own right.
However, it so happens that we have a mechanism for transferring value across multiple cryptocurrency systems: the HTLC.
2-of-2 is also the most stable.
This is because *all* signatories of an n-of-n cryptocurrency system need to be online at the same time in order for *any* of them to use the funds in the system.
If any one of them is offline, then the system is unusable.
With 2 participants, there is some probability that one of them is offline and the individual 2-of-2 system is unusable.
With 3 participants, the probability is higher (there are more participants that can be offline).
With 4 participants, higher still.
Thus, the most stable is to split Bitcoin into lots of little 2-of-2 systems, and use HTLCs to transfer funds across the little 2-of-2 systems.
Thus, Lightning Network, which splits Bitcoin into lots of little 2-of-2 cryptocurrency systems (channels), and uses HTLCs to atomically transfer value across them (routing).
Of course, having larger n is better as we need to splinter Bitcoin into fewer funds with larger participant sets.
And we can mitigate the offline-problem by using a two-layer system: we have a n-of-n system (n > 2) that itself splits into multiple smaller 2-of-2 systems.
That way, the Bitcoin layer is split into fewer UTXOs, reducing blockchain resource consumption further.
Thus, Channel Factories hosting Lightning Channels.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
` (2 preceding siblings ...)
2021-06-20 0:53 ` ZmnSCPxj
@ 2021-06-20 1:59 ` James Hilliard
2021-06-22 18:20 ` Billy Tetrud
3 siblings, 1 reply; 41+ messages in thread
From: James Hilliard @ 2021-06-20 1:59 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
I think you're making a number of assumptions about mining that are
not accurate.
> First of all, how much chance in finding next block the corrupted miners have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10? The cheaters must come up in dividing that 1.2 Bitcoin between. After all the risk/reward must fit them. They can not be a big mining pool since there is no benefit, so they will be small miners with low hash rate. If they solve the puzzle and broadcast the block, no one in the entire Bitcoin network has block transactions or seen it before in their mempool!
You're making the assumption that miners won't build on top of a block
with transactions they have not seen before or transactions that may
contain double spends of unconfirmed inputs, this is not how mining
works, as long as the block passes the consensus rules effectively all
miners will mine on top of it by default, this behavior is fundamental
to how mining currently works and is fairly deeply baked into the
current mining infrastructure.
> Will they accept this block? In theory it is possible and have 0.01 percent chance but we can eliminate this small possibilities by a simple BIP for miners.
What would this BIP look like? I don't see how this could work in a
decentralized way as you would need another way of reaching consensus
on what defines a valid block. Right now the chance is nearly 100
percent that a miner will mine on top of the latest valid block, many
pools(most last I checked) will even mine on the next block before
they validate the latest block fully(ie validationless mining) to
reduce their orphan rates.
> We suppose the miners always control transactions with doc-watchers and avoid accepting transaction with same UTXO but different output.
Miners have different mempool policy/rules for what transactions they
themselves mine but all miners must mine on the most work chain of
valid blocks otherwise they risk their own blocks being orphaned, any
miner that does not do this is effectively guaranteed to have their
block orphaned right now.
> Because of high Bitcoin transaction fee, this guarantee transaction will take place in next block, even if other transaction which are using the same UTXO as input existed in mempool.
When a new transaction is broadcast miners do not immediately start
mining on a block template that includes that transaction, the
template won't even be generated immediately when it enters a miners
mempool in practice, for bandwidth/network efficiency reasons mining
pools batch update the stratum templates/jobs they mine against so
there can be significant latency between the time a transaction is
actually broadcast and hits the miners mempool and the time the miners
actually switch to mining on top it, these batched updates are
essentially like point in time snapshots of the mempool and typically
remain valid(as in the pool will accept shares submitted against that
job as valid) until the bitcoin network finds the next block. I don't
think these batch updates are done more often than every 30 seconds
typically, while often it is on the order of multiple minutes
depending on the pool.
Regards,
James
On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
<bitcoin-dev@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-20 1:59 ` James Hilliard
@ 2021-06-22 18:20 ` Billy Tetrud
2021-07-01 20:11 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Billy Tetrud @ 2021-06-22 18:20 UTC (permalink / raw)
To: James Hilliard, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5183 bytes --]
I would be interested in seeing some more information about the benefits of
this approach vs alternatives up front in this write up. Eg how does the
security, cost, usability, and privacy compare to the lightning network,
which would be the most likely competitor to this idea. It seems clear that
there is more counterparty risk here, so it would probably also be very
helpful to compare against traditional custodial solutions as well. If you
have specific claims on how this system is better than eg lightning in
certain contexts, it would be far easier to evaluate the protocol against
those claims, and would also be a lot easier for readers to be motivated to
read the whole protocol and do a more full analysis.
I agree with others that using email is probably not appropriate for a
protocol like this. I would highly recommend making your protocol
transport-agnostic, allowing users of your protocol to use any transport
they want.
On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I think you're making a number of assumptions about mining that are
> not accurate.
>
> > First of all, how much chance in finding next block the corrupted miners
> have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10?
> The cheaters must come up in dividing that 1.2 Bitcoin between. After all
> the risk/reward must fit them. They can not be a big mining pool since
> there is no benefit, so they will be small miners with low hash rate. If
> they solve the puzzle and broadcast the block, no one in the entire Bitcoin
> network has block transactions or seen it before in their mempool!
>
> You're making the assumption that miners won't build on top of a block
> with transactions they have not seen before or transactions that may
> contain double spends of unconfirmed inputs, this is not how mining
> works, as long as the block passes the consensus rules effectively all
> miners will mine on top of it by default, this behavior is fundamental
> to how mining currently works and is fairly deeply baked into the
> current mining infrastructure.
>
> > Will they accept this block? In theory it is possible and have 0.01
> percent chance but we can eliminate this small possibilities by a simple
> BIP for miners.
>
> What would this BIP look like? I don't see how this could work in a
> decentralized way as you would need another way of reaching consensus
> on what defines a valid block. Right now the chance is nearly 100
> percent that a miner will mine on top of the latest valid block, many
> pools(most last I checked) will even mine on the next block before
> they validate the latest block fully(ie validationless mining) to
> reduce their orphan rates.
>
> > We suppose the miners always control transactions with doc-watchers and
> avoid accepting transaction with same UTXO but different output.
>
> Miners have different mempool policy/rules for what transactions they
> themselves mine but all miners must mine on the most work chain of
> valid blocks otherwise they risk their own blocks being orphaned, any
> miner that does not do this is effectively guaranteed to have their
> block orphaned right now.
>
> > Because of high Bitcoin transaction fee, this guarantee transaction will
> take place in next block, even if other transaction which are using the
> same UTXO as input existed in mempool.
>
> When a new transaction is broadcast miners do not immediately start
> mining on a block template that includes that transaction, the
> template won't even be generated immediately when it enters a miners
> mempool in practice, for bandwidth/network efficiency reasons mining
> pools batch update the stratum templates/jobs they mine against so
> there can be significant latency between the time a transaction is
> actually broadcast and hits the miners mempool and the time the miners
> actually switch to mining on top it, these batched updates are
> essentially like point in time snapshots of the mempool and typically
> remain valid(as in the pool will accept shares submitted against that
> job as valid) until the bitcoin network finds the next block. I don't
> think these batch updates are done more often than every 30 seconds
> typically, while often it is on the order of multiple minutes
> depending on the pool.
>
> Regards,
> James
>
> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> <bitcoin-dev@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@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6494 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-20 0:53 ` ZmnSCPxj
@ 2021-06-26 21:54 ` raymo
2021-06-27 4:53 ` ZmnSCPxj
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-26 21:54 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Good morning ZmnSCPxj
Sorry for late reply.
> Guarantee Transactions (GT) being higher-fee is ***not*** assured.
The question is “assuring what?”.
The whole point of my proposal is the fact that issuers and creditors
act rationally and won't harm their selves. The numbers (input and
output amounts), the relation between inputs and outputs amounts, the
minimum and maximum of inputs and outputs amounts, and conditions of a
valid trans-action in Sabu protocol are all designed precisely to
leading the rational users toward the making profit from the system. And
irrationals (either issuer or creditor) can harm the others and
inevitably in con-sequence will hurt themselves too. So, there is a fair
and just transaction (MT).
The creditor can send the GT to Bitcoin network and lose 70% of his
money and damage 15% of is-suer money!
Vice versa the issuer can send GT to Bitcoin network and harm itself 15%
in cost of hurt creditors 70% which is none sense. Or issuer can pay
even more money directly to miner and hurt itself even more which is
even more irrational! Or the miner will ignore the transaction fees of a
GT and put the fraudulent transaction in next block, which I cannot
imagine a miner that pass up his legal and legiti-mate income in favor
of a greedy issuer!
Please write me a scenario (preferably with clear amount of inputs and
outputs) by which the cheater (either issuer or creditor) gains more
profit than playing honestly.
Only in this case we can accept your claim about weakness of protocol.
> Every offchain protocol needs *the receiver* as a signatory to any unconfirmed transaction. the receiver **must** be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does *not* have the receiver as a signatory.
I intentionally decided to not using 2 of 2 signature, because I didn't
want to fall in same trap as Light-ening. I wanted to avoid this long
drilling 2 of 2 signings and routing. Instead, I just proposed to
cre-ate and sign a valid Bitcoin transaction between only 2 people in a
pure-peer-to-peer communication. The only signer is the issuer (the UTXO
owner).
Again, same logic. Please write me a scenario by which the cheater
(issuer or creditor) can cheat this only-issuer-signed transactions and
gains more profit than playing honest. Due to numbers and trans-action
restrictions and the insignificance of the amount of each transaction
this scenario of fraud will fail too.
Looking forward to hearing from you
Raymo
On 2021-06-20 00:53, ZmnSCPxj wrote:
> Good morning Raymo,
>
>> 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.
>
>
> Guarantee Transactions (GT) being higher-fee is ***not*** assured.
>
> Feerates are always bumpable --- the sender of a transaction only
> needs to directly contact a miner and offer a fee to take a specific
> transaction on the next block proposal, conditional on the transaction
> *actually* getting into a block.
> Such "side fees" are always possible.
> Indeed, the in-transaction fees are "just" a way to anonymously and
> atomically make that fee offer to miners --- but miners and issuers
> can always communicate directly without using Bitcoin transaction to
> arrange a higher fee for a fraudulent Main Transaction (MT).
>
> because of this, you should really treat all unconfirmed transactions
> --- including MTs and GTs --- as potentially replaceable, i.e.
> RBFable.
> There is no such thing as "RBF disabled", all transactions are
> inherently RBF-able due to side fees --- it is simply a matter of
> anonymity, atomicity, and ease-of-use.
>
> ---
>
> Every offchain protocol needs *the receiver* as a signatory to any
> unconfirmed transaction.
>
> Or more strongly, the receiver **must** be a signatory --- the
> receiver cannot trust an unconfirmed transaction where the spent UTXO
> has an alternate branch that does *not* have the receiver as a
> signatory.
>
> See: https://zmnscpxj.github.io/offchain/safety.html
>
> Thus, all safe offchain schemes need to use an n-of-n signing set.
>
> The smallest n-of-n that is still useful is 2-of-2, where one
> participant is a sender and the other is a receiver.
> (1-of-1 is not useful since there is no possible receiver who can sign).
>
> This requires Bitcoin to splinter into lots of 2-of-2 funds, each one
> a sovereign sub-money (that is *eventually* convertible to Bitcoin),
> each one a cryptocurrency system in its own right.
> However, it so happens that we have a mechanism for transferring value
> across multiple cryptocurrency systems: the HTLC.
>
> 2-of-2 is also the most stable.
> This is because *all* signatories of an n-of-n cryptocurrency system
> need to be online at the same time in order for *any* of them to use
> the funds in the system.
> If any one of them is offline, then the system is unusable.
> With 2 participants, there is some probability that one of them is
> offline and the individual 2-of-2 system is unusable.
> With 3 participants, the probability is higher (there are more
> participants that can be offline).
> With 4 participants, higher still.
>
> Thus, the most stable is to split Bitcoin into lots of little 2-of-2
> systems, and use HTLCs to transfer funds across the little 2-of-2
> systems.
>
> Thus, Lightning Network, which splits Bitcoin into lots of little
> 2-of-2 cryptocurrency systems (channels), and uses HTLCs to atomically
> transfer value across them (routing).
>
>
> Of course, having larger n is better as we need to splinter Bitcoin
> into fewer funds with larger participant sets.
> And we can mitigate the offline-problem by using a two-layer system:
> we have a n-of-n system (n > 2) that itself splits into multiple
> smaller 2-of-2 systems.
> That way, the Bitcoin layer is split into fewer UTXOs, reducing
> blockchain resource consumption further.
>
> Thus, Channel Factories hosting Lightning Channels.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-26 21:54 ` raymo
@ 2021-06-27 4:53 ` ZmnSCPxj
2021-06-27 11:05 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: ZmnSCPxj @ 2021-06-27 4:53 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
Good morning Raymo,
> Good morning ZmnSCPxj
> Sorry for late reply.
>
> > Guarantee Transactions (GT) being higher-fee is not assured.
>
> The question is “assuring what?”.
> The whole point of my proposal is the fact that issuers and creditors
> act rationally and won't harm their selves. The numbers (input and
> output amounts), the relation between inputs and outputs amounts, the
> minimum and maximum of inputs and outputs amounts, and conditions of a
> valid trans-action in Sabu protocol are all designed precisely to
> leading the rational users toward the making profit from the system. And
> irrationals (either issuer or creditor) can harm the others and
> inevitably in con-sequence will hurt themselves too. So, there is a fair
> and just transaction (MT).
> The creditor can send the GT to Bitcoin network and lose 70% of his
> money and damage 15% of is-suer money!
> Vice versa the issuer can send GT to Bitcoin network and harm itself 15%
> in cost of hurt creditors 70% which is none sense. Or issuer can pay
> even more money directly to miner and hurt itself even more which is
> even more irrational! Or the miner will ignore the transaction fees of a
> GT and put the fraudulent transaction in next block, which I cannot
> imagine a miner that pass up his legal and legiti-mate income in favor
> of a greedy issuer!
> Please write me a scenario (preferably with clear amount of inputs and
> outputs) by which the cheater (either issuer or creditor) gains more
> profit than playing honestly.
> Only in this case we can accept your claim about weakness of protocol.
>
> > Every offchain protocol needs the receiver as a signatory to any unconfirmed transaction. the receiver must be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does not have the receiver as a signatory.
>
> I intentionally decided to not using 2 of 2 signature, because I didn't
> want to fall in same trap as Light-ening. I wanted to avoid this long
> drilling 2 of 2 signings and routing. Instead, I just proposed to
> cre-ate and sign a valid Bitcoin transaction between only 2 people in a
> pure-peer-to-peer communication. The only signer is the issuer (the UTXO
> owner).
> Again, same logic. Please write me a scenario by which the cheater
> (issuer or creditor) can cheat this only-issuer-signed transactions and
> gains more profit than playing honest. Due to numbers and trans-action
> restrictions and the insignificance of the amount of each transaction
> this scenario of fraud will fail too.
As the issuer is the only one signing, it can trivially create a self-paying transaction by itself that is neither a valid MT nor a valid GT.
Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change output back to me.
After you hand over the equivalent of 1 BTC in other resources, I then create an alternative transaction, signed only by myself, paying 0.5 BTC to miners and 1.5 BTC to myself, and since the fee is so high, the miners have every incentive to mine it.
Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain layer requires that the *single* signer follow the protocol.
The point here is that a single signer can sign anything, including a transaction that is not an MT or a GT, but has arbitrary numbers that are neither a valid GT nor a valid MT.
That is the reason why every trust-minimized offchain system requires 2-of-2, somebody else has to countercheck the validity of a protocol that is *not* directly on the blockchain.
The blockchain only cares about signature and timelock validity; it does not care about (and check for validity) MTs and GTs.
In essence, this is a trusted system where every creditor trusts every issuer to *only* sign GTs and MTs, thus uninteresting --- you might as well just use Coinbase as your offchain if you are going to inject trust.
Now you can counterargue that you intend this system to be used for small payments and thus the fee for this non-MT non-GT clawback can approach the security levels you so carefully computed for GT and MT, but again --- the *largest* safe payment will vary depending on onchain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times.
This uncertainty is not handled well by most users, thus I think your UX will be fairly awful.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-27 4:53 ` ZmnSCPxj
@ 2021-06-27 11:05 ` raymo
2021-06-28 5:20 ` ZmnSCPxj
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-27 11:05 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
On 2021-06-27 04:53, ZmnSCPxj wrote:
Good evening ZmnSCPxj
It looks you already missed the entire design of Sabu and its
restrictions. First of all, the Gazin wallet always controls the Sabu
restrictions for every transaction in order to consider it as a valid
transaction in a valid deal. That is, the creditor wallet controls the
MT and GT in first place. Then if the transactions are valid the
creditor consider entire process as a valid deal and give the services
or goods in exchange of received Satoshis.
So, in this scenario the issuer has to sign a MT transaction in which
the issuer spends a UTXO worth at least 40,000 Sat, and issuer can issue
maximum 20,000 Sat debt-document. So, the transaction can have One or
more outputs for creditor(s), they must worth in total less than 20,000
Sat.
Each transaction has to pay fixed 10,000 Sat as BTC-transaction-fee
regardless the transaction length or the inputs/outputs amounts. The
issuer always pays at least 4,000 Sat of BTC-transaction-fee, and the
6,000 remined fee must be paid by issuer and creditors in proportion to
their outputs amounts)
Finally, the transaction can have one change-back output to issuer
address (same as input address) worth less than (40,000 – 4,000=36,000)
Sat to issuer. This value depends on the debt amount and the issuer
BTC-transaction-fee portion. The maximum issuer change back could be
(40,000 -10,000 = 30,000) Sat for a transaction with no debt issuance.
The minimum amount of change back would be (40,000 – 10,000 – 19,999 =
10,001 Sat). For more details, please take a look at figure 3.
(Transaction in detail) in article
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
also investigate on code
https://github.com/raymaot/transaction-numbers-and-coefficients .
The creditor controls all these criteria and after passing all these
tests the creditor accept transaction as a valid transaction. Now
creditor has 2 MT and GT transaction in his hand.
Because of these number limitations, no arbitrary UTXO spending by
issuer nor self-paying transaction can make more output and more
benefits to him than respecting the already issued MT. please
investigate on figure 1.0. (Security checks) for more details.
Now show me a case (with precise amounts of inputs and outputs) that
fits in Sabu restrictions AND issuer can make an arbitrary transaction
with more benefit than MT!
> the *largest* safe payment will vary depending on onchain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times.
All these transactions are formed relatively (the numbers in GT are
calculated based on MT), so they are relative, so no matter how much
mempool is full or empty. The only consideration for mempool is the
propagation delay which is another story and has its own solution as
well.
> I think your UX will be fairly awful.
All validations and communications are behind the scene, so the UX will
be enough smooth and friendly except the latency of email-based
communications, which needs to be considered in details. BTW this is not
a big deal considering the sovereignty and the freedom are bringing to
our financial activities.
> Good morning Raymo,
>
>
>> Good morning ZmnSCPxj
>> Sorry for late reply.
>>
>> > Guarantee Transactions (GT) being higher-fee is not assured.
>>
>> The question is “assuring what?”.
>> The whole point of my proposal is the fact that issuers and creditors
>> act rationally and won't harm their selves. The numbers (input and
>> output amounts), the relation between inputs and outputs amounts, the
>> minimum and maximum of inputs and outputs amounts, and conditions of a
>> valid trans-action in Sabu protocol are all designed precisely to
>> leading the rational users toward the making profit from the system. And
>> irrationals (either issuer or creditor) can harm the others and
>> inevitably in con-sequence will hurt themselves too. So, there is a fair
>> and just transaction (MT).
>> The creditor can send the GT to Bitcoin network and lose 70% of his
>> money and damage 15% of is-suer money!
>> Vice versa the issuer can send GT to Bitcoin network and harm itself 15%
>> in cost of hurt creditors 70% which is none sense. Or issuer can pay
>> even more money directly to miner and hurt itself even more which is
>> even more irrational! Or the miner will ignore the transaction fees of a
>> GT and put the fraudulent transaction in next block, which I cannot
>> imagine a miner that pass up his legal and legiti-mate income in favor
>> of a greedy issuer!
>> Please write me a scenario (preferably with clear amount of inputs and
>> outputs) by which the cheater (either issuer or creditor) gains more
>> profit than playing honestly.
>> Only in this case we can accept your claim about weakness of protocol.
>>
>> > Every offchain protocol needs the receiver as a signatory to any unconfirmed transaction. the receiver must be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does not have the receiver as a signatory.
>>
>> I intentionally decided to not using 2 of 2 signature, because I didn't
>> want to fall in same trap as Light-ening. I wanted to avoid this long
>> drilling 2 of 2 signings and routing. Instead, I just proposed to
>> cre-ate and sign a valid Bitcoin transaction between only 2 people in a
>> pure-peer-to-peer communication. The only signer is the issuer (the UTXO
>> owner).
>> Again, same logic. Please write me a scenario by which the cheater
>> (issuer or creditor) can cheat this only-issuer-signed transactions and
>> gains more profit than playing honest. Due to numbers and trans-action
>> restrictions and the insignificance of the amount of each transaction
>> this scenario of fraud will fail too.
>
> As the issuer is the only one signing, it can trivially create a
> self-paying transaction by itself that is neither a valid MT nor a
> valid GT.
>
> Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change
> output back to me.
> After you hand over the equivalent of 1 BTC in other resources, I then
> create an alternative transaction, signed only by myself, paying 0.5
> BTC to miners and 1.5 BTC to myself, and since the fee is so high, the
> miners have every incentive to mine it.
>
> Yes, that is not a valid MT or GT, but nothing in the Bitcoin
> blockchain layer requires that the *single* signer follow the
> protocol.
> The point here is that a single signer can sign anything, including a
> transaction that is not an MT or a GT, but has arbitrary numbers that
> are neither a valid GT nor a valid MT.
> That is the reason why every trust-minimized offchain system requires
> 2-of-2, somebody else has to countercheck the validity of a protocol
> that is *not* directly on the blockchain.
> The blockchain only cares about signature and timelock validity; it
> does not care about (and check for validity) MTs and GTs.
>
> In essence, this is a trusted system where every creditor trusts every
> issuer to *only* sign GTs and MTs, thus uninteresting --- you might as
> well just use Coinbase as your offchain if you are going to inject
> trust.
>
> Now you can counterargue that you intend this system to be used for
> small payments and thus the fee for this non-MT non-GT clawback can
> approach the security levels you so carefully computed for GT and MT,
> but again --- the *largest* safe payment will vary depending on
> onchain mempool state, and if the mempool is almost empty, the largest
> safe payment will be much smaller than at other times.
> This uncertainty is not handled well by most users, thus I think your
> UX will be fairly awful.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-27 11:05 ` raymo
@ 2021-06-28 5:20 ` ZmnSCPxj
2021-06-28 6:29 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: ZmnSCPxj @ 2021-06-28 5:20 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
Good morning Raymo,
>
> It looks you already missed the entire design of Sabu and its
> restrictions. First of all, the Gazin wallet always controls the Sabu
> restrictions for every transaction in order to consider it as a valid
> transaction in a valid deal. That is, the creditor wallet controls the
> MT and GT in first place.
Stop right there.
From the above, what I get is, "trust the Gazin wallet".
Thus, the suggestion to just use Coinbase.
At least it has existed longer and has more current users that trust it, rather than this Gazin thing.
Is Gazin open-source?
* If Gazin is open-source, I could download the source code, make a local copy that gives me a separate copy of the keys, and use the keys to sign any transaction I want.
* If Gazin is not open-source, then why should I trust the Gazin wallet until my incoming funds to an open-source wallet I control have been confirmed deeply?
Lightning is still superior because:
* It can be open-sourced completely and even though I have keys to my onchain funds, I *still* cannot steal the funds of my counterparty.
* Even if I connect my open-source node to a node with a closed-source implementation, I know I can rely on receives from that node without waiting for the transaction to be confirmed deeply.
All the benefits your scheme claims, are derived from the trust assumption, which is uninteresting, we already have those, they are called custodial wallets.
Lightning allows for non-custodiality while achieving high global TPS and low fees.
And a central idea of Lightning is the requirement to use an n-of-n to form smaller sub-moneys from the global money.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 5:20 ` ZmnSCPxj
@ 2021-06-28 6:29 ` raymo
2021-06-28 8:23 ` James Hilliard
2021-06-28 15:28 ` ZmnSCPxj
0 siblings, 2 replies; 41+ messages in thread
From: raymo @ 2021-06-28 6:29 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
Why you get the signal “trust the Gazin wallet”?
Sabu is a protocol and the Gazin wallet will be an implementation of
that protocol. We will implement it in react-native language to support
both Android and iPhone. Of course it will be open source and GPL3.
Here is the repository and yet is empty :)
https://github.com/raymaot/Gazin
I wonder why you do not look carefully into the proposal! IMHO the Sabu
will be far better than Lightning.
Can’t you see the fact that in Sabu you do not need open and close
channels ever? Can you imagine only this feature how dramatically
decrease the transactions cost and how increase the distribution of
nodes and improve privacy level? it makes every mobile wallet act like a
lightning network.
Did you note the fact that in Sabu protocol there is no routing? And the
only people knew about a transaction are issuer and creditor? No one
else won’t be aware of transactions and million transactions per second
can be sent and received and repeal dynamically without any footprint on
any DLT?
The English is not my mother language and probably my paper is not a
smooth and easy to read paper, but these are not good excuse to not even
reading a technical paper carefully and before understanding it or at
least trying to understanding it start to complaining.
> All the benefits your scheme claims, are derived from the trust assumption
No, All the benefits my scheme claims, are derived from economically
rational decision of both issuer and creditors.
Regards
Raymo
On 2021-06-28 05:20, ZmnSCPxj wrote:
> Good morning Raymo,
>
>>
>> It looks you already missed the entire design of Sabu and its
>> restrictions. First of all, the Gazin wallet always controls the Sabu
>> restrictions for every transaction in order to consider it as a valid
>> transaction in a valid deal. That is, the creditor wallet controls the
>> MT and GT in first place.
>
> Stop right there.
>
> From the above, what I get is, "trust the Gazin wallet".
> Thus, the suggestion to just use Coinbase.
> At least it has existed longer and has more current users that trust
> it, rather than this Gazin thing.
>
>
> Is Gazin open-source?
>
> * If Gazin is open-source, I could download the source code, make a
> local copy that gives me a separate copy of the keys, and use the keys
> to sign any transaction I want.
> * If Gazin is not open-source, then why should I trust the Gazin
> wallet until my incoming funds to an open-source wallet I control have
> been confirmed deeply?
>
> Lightning is still superior because:
>
> * It can be open-sourced completely and even though I have keys to my
> onchain funds, I *still* cannot steal the funds of my counterparty.
> * Even if I connect my open-source node to a node with a closed-source
> implementation, I know I can rely on receives from that node without
> waiting for the transaction to be confirmed deeply.
>
>
> All the benefits your scheme claims, are derived from the trust
> assumption, which is uninteresting, we already have those, they are
> called custodial wallets.
> Lightning allows for non-custodiality while achieving high global TPS
> and low fees.
> And a central idea of Lightning is the requirement to use an n-of-n to
> form smaller sub-moneys from the global money.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 6:29 ` raymo
@ 2021-06-28 8:23 ` James Hilliard
2021-06-28 9:52 ` raymo
2021-06-28 15:28 ` ZmnSCPxj
1 sibling, 1 reply; 41+ messages in thread
From: James Hilliard @ 2021-06-28 8:23 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi ZmnSCPxj,
>
> Why you get the signal “trust the Gazin wallet”?
> Sabu is a protocol and the Gazin wallet will be an implementation of
> that protocol. We will implement it in react-native language to support
> both Android and iPhone. Of course it will be open source and GPL3.
> Here is the repository and yet is empty :)
> https://github.com/raymaot/Gazin
>
> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> will be far better than Lightning.
> Can’t you see the fact that in Sabu you do not need open and close
> channels ever? Can you imagine only this feature how dramatically
> decrease the transactions cost and how increase the distribution of
> nodes and improve privacy level? it makes every mobile wallet act like a
> lightning network.
> Did you note the fact that in Sabu protocol there is no routing? And the
> only people knew about a transaction are issuer and creditor? No one
> else won’t be aware of transactions and million transactions per second
> can be sent and received and repeal dynamically without any footprint on
> any DLT?
>
> The English is not my mother language and probably my paper is not a
> smooth and easy to read paper, but these are not good excuse to not even
> reading a technical paper carefully and before understanding it or at
> least trying to understanding it start to complaining.
Considering that you have not effectively addressed any of the inaccurate
assumptions made regarding how mining works that I pointed out earlier
I assume your proposal is not viable in practice.
See:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
>
> > All the benefits your scheme claims, are derived from the trust assumption
> No, All the benefits my scheme claims, are derived from economically
> rational decision of both issuer and creditors.
>
> Regards
> Raymo
>
>
>
> On 2021-06-28 05:20, ZmnSCPxj wrote:
> > Good morning Raymo,
> >
> >>
> >> It looks you already missed the entire design of Sabu and its
> >> restrictions. First of all, the Gazin wallet always controls the Sabu
> >> restrictions for every transaction in order to consider it as a valid
> >> transaction in a valid deal. That is, the creditor wallet controls the
> >> MT and GT in first place.
> >
> > Stop right there.
> >
> > From the above, what I get is, "trust the Gazin wallet".
> > Thus, the suggestion to just use Coinbase.
> > At least it has existed longer and has more current users that trust
> > it, rather than this Gazin thing.
> >
> >
> > Is Gazin open-source?
> >
> > * If Gazin is open-source, I could download the source code, make a
> > local copy that gives me a separate copy of the keys, and use the keys
> > to sign any transaction I want.
> > * If Gazin is not open-source, then why should I trust the Gazin
> > wallet until my incoming funds to an open-source wallet I control have
> > been confirmed deeply?
> >
> > Lightning is still superior because:
> >
> > * It can be open-sourced completely and even though I have keys to my
> > onchain funds, I *still* cannot steal the funds of my counterparty.
> > * Even if I connect my open-source node to a node with a closed-source
> > implementation, I know I can rely on receives from that node without
> > waiting for the transaction to be confirmed deeply.
> >
> >
> > All the benefits your scheme claims, are derived from the trust
> > assumption, which is uninteresting, we already have those, they are
> > called custodial wallets.
> > Lightning allows for non-custodiality while achieving high global TPS
> > and low fees.
> > And a central idea of Lightning is the requirement to use an n-of-n to
> > form smaller sub-moneys from the global money.
> >
> > Regards,
> > ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 8:23 ` James Hilliard
@ 2021-06-28 9:52 ` raymo
2021-06-28 11:28 ` James Hilliard
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-28 9:52 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Protocol Discussion
Hi James,
Sorry for not responding in detail.
So, lets jump in the critiques.
> You're making the assumption that miners won't build on top of a block
with transactions they have not seen before or transactions that may
contain double spends of unconfirmed inputs
No, it is a wish. I hope in future miners consider this rule as well.
But for now, I absolutely do not count on this restriction. So, miner
can/will accept a valid block which contains some valid transactions
which they didn’t aware of those transactions in advance.
In order to explain how economically this won’t happened, I have to
refer you to the fact that a conspiracy between a miner(mining pool) and
a group of issuers to mine a block full of cheating transaction will
makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
now). The 1.2 is coming from average(max) 6,000 transaction per block *
max 20K Satoshi cheating benefit for each promised used UTXO in a
debt-doc(transaction).
In order to achieve this conspiracy, the mining pool has to mine the
block in stealth, lonely and without broadcasting any of transactions to
Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
they have to change the block header and restart again. After all, if
they succeed, they have to divide this extra dirty 1.2 BTC in between. I
I am not expert in mining pool calculations; you may help me to answer
these questions?
Consider these given facts:
More hashrate = more success chance.
More hashrate = more electric cost = less profit per each participator
There is a minimum hashrate to have a minimum chance to solve the puzzle
in next 10 minutes, otherwise it doesn't make sense to participate in an
activity that doesn't fit the minimum hope.
How much is this minimum hashrate?
How much costs this hashrate?
Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
be economically cost effective (risk to reward) to dedicate your
hashrate to mine this block? I am not sure. But if you show me the
opposite by facts and numbers, I will highly appreciate you.
> What would this BIP look like?
> We suppose the miners always control transactions with doc-watchers
As I told before, these assumptions are my wishes and I never relayed on
these wishes. These are for future. For now, I just count on the
calculation that asked you to help.
> there can be significant latency between the time a transaction is
actually broadcast and hits the miners mempool and the time the miners
actually switch to mining on top it
It is great. Although this latency could be lesser (in case of empty
mempools), but Sabu likes this latency. Because the creditors will have
more time to be aware of a fraudulent activity from issuer and existence
of a cheating transaction in mempool, so they have more time to send and
broad cast the GT to network. More latency, more chance in batch update.
So more chance for miners to face two or three transactions which are
using same UTXO but sending to different addresses and paying different
fees.
More latency increases the chance of putting the higher-fee-payer
transaction in next block.
Regards
Raymo
On 2021-06-28 08:23, James Hilliard wrote:
> On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Hi ZmnSCPxj,
>>
>> Why you get the signal “trust the Gazin wallet”?
>> Sabu is a protocol and the Gazin wallet will be an implementation of
>> that protocol. We will implement it in react-native language to support
>> both Android and iPhone. Of course it will be open source and GPL3.
>> Here is the repository and yet is empty :)
>> https://github.com/raymaot/Gazin
>>
>> I wonder why you do not look carefully into the proposal! IMHO the Sabu
>> will be far better than Lightning.
>> Can’t you see the fact that in Sabu you do not need open and close
>> channels ever? Can you imagine only this feature how dramatically
>> decrease the transactions cost and how increase the distribution of
>> nodes and improve privacy level? it makes every mobile wallet act like a
>> lightning network.
>> Did you note the fact that in Sabu protocol there is no routing? And the
>> only people knew about a transaction are issuer and creditor? No one
>> else won’t be aware of transactions and million transactions per second
>> can be sent and received and repeal dynamically without any footprint on
>> any DLT?
>>
>> The English is not my mother language and probably my paper is not a
>> smooth and easy to read paper, but these are not good excuse to not even
>> reading a technical paper carefully and before understanding it or at
>> least trying to understanding it start to complaining.
>
> Considering that you have not effectively addressed any of the inaccurate
> assumptions made regarding how mining works that I pointed out earlier
> I assume your proposal is not viable in practice.
>
> See:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
>
>>
>> > All the benefits your scheme claims, are derived from the trust assumption
>> No, All the benefits my scheme claims, are derived from economically
>> rational decision of both issuer and creditors.
>>
>> Regards
>> Raymo
>>
>>
>>
>> On 2021-06-28 05:20, ZmnSCPxj wrote:
>> > Good morning Raymo,
>> >
>> >>
>> >> It looks you already missed the entire design of Sabu and its
>> >> restrictions. First of all, the Gazin wallet always controls the Sabu
>> >> restrictions for every transaction in order to consider it as a valid
>> >> transaction in a valid deal. That is, the creditor wallet controls the
>> >> MT and GT in first place.
>> >
>> > Stop right there.
>> >
>> > From the above, what I get is, "trust the Gazin wallet".
>> > Thus, the suggestion to just use Coinbase.
>> > At least it has existed longer and has more current users that trust
>> > it, rather than this Gazin thing.
>> >
>> >
>> > Is Gazin open-source?
>> >
>> > * If Gazin is open-source, I could download the source code, make a
>> > local copy that gives me a separate copy of the keys, and use the keys
>> > to sign any transaction I want.
>> > * If Gazin is not open-source, then why should I trust the Gazin
>> > wallet until my incoming funds to an open-source wallet I control have
>> > been confirmed deeply?
>> >
>> > Lightning is still superior because:
>> >
>> > * It can be open-sourced completely and even though I have keys to my
>> > onchain funds, I *still* cannot steal the funds of my counterparty.
>> > * Even if I connect my open-source node to a node with a closed-source
>> > implementation, I know I can rely on receives from that node without
>> > waiting for the transaction to be confirmed deeply.
>> >
>> >
>> > All the benefits your scheme claims, are derived from the trust
>> > assumption, which is uninteresting, we already have those, they are
>> > called custodial wallets.
>> > Lightning allows for non-custodiality while achieving high global TPS
>> > and low fees.
>> > And a central idea of Lightning is the requirement to use an n-of-n to
>> > form smaller sub-moneys from the global money.
>> >
>> > Regards,
>> > ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 9:52 ` raymo
@ 2021-06-28 11:28 ` James Hilliard
2021-06-28 16:33 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: James Hilliard @ 2021-06-28 11:28 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup•net> wrote:
>
>
> Hi James,
> Sorry for not responding in detail.
> So, lets jump in the critiques.
>
> > You're making the assumption that miners won't build on top of a block
> with transactions they have not seen before or transactions that may
> contain double spends of unconfirmed inputs
> No, it is a wish. I hope in future miners consider this rule as well.
There's only one practical approach I'm aware of for miners to actually
do this, and that would be to effectively make mining centralized.
So I would highly discourage this sort of policy when it comes to mining.
> But for now, I absolutely do not count on this restriction. So, miner
> can/will accept a valid block which contains some valid transactions
> which they didn’t aware of those transactions in advance.
Mempools among miners are generally not fully in sync with each other,
rejecting valid blocks due to disagreements over which transactions were
broadcast would destabilize the network as you'd get a bunch of network
forks.
> In order to explain how economically this won’t happened, I have to
> refer you to the fact that a conspiracy between a miner(mining pool) and
> a group of issuers to mine a block full of cheating transaction will
> makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
> now). The 1.2 is coming from average(max) 6,000 transaction per block *
> max 20K Satoshi cheating benefit for each promised used UTXO in a
> debt-doc(transaction).
But there's no risk really for a miner to choose the most profitable
transactions to mine as long as they are valid per the network rules,
that is unless you make mining fully centralized.
> In order to achieve this conspiracy, the mining pool has to mine the
> block in stealth, lonely and without broadcasting any of transactions to
> Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
> they have to change the block header and restart again. After all, if
> they succeed, they have to divide this extra dirty 1.2 BTC in between. I
Miners regularly change block headers, and if they don't broadcast the
transactions there wouldn't really be a time limit, so even a relatively small
miner would be able to stealthily mine the transactions given enough time.
>
>
> I am not expert in mining pool calculations; you may help me to answer
> these questions?
>
> Consider these given facts:
>
> More hashrate = more success chance.
> More hashrate = more electric cost = less profit per each participator
> There is a minimum hashrate to have a minimum chance to solve the puzzle
> in next 10 minutes, otherwise it doesn't make sense to participate in an
> activity that doesn't fit the minimum hope.
Why would they need to solve the block within 10 minutes?
> How much is this minimum hashrate?
I don't think there is a minimum.
> How much costs this hashrate?
Miners just use pools to reduce variance, there isn't a set minimum size to
solo mine, only how much variance the miner can tolerate.
> Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
> be economically cost effective (risk to reward) to dedicate your
> hashrate to mine this block? I am not sure. But if you show me the
> opposite by facts and numbers, I will highly appreciate you.
All that matters is if that extra is more than they would otherwise get.
>
> > What would this BIP look like?
> > We suppose the miners always control transactions with doc-watchers
> As I told before, these assumptions are my wishes and I never relayed on
> these wishes. These are for future. For now, I just count on the
> calculation that asked you to help.
The reason I ask is because I don't think this is possible to do
without massively
centralizing mining.
>
> > there can be significant latency between the time a transaction is
> actually broadcast and hits the miners mempool and the time the miners
> actually switch to mining on top it
>
> It is great. Although this latency could be lesser (in case of empty
> mempools), but Sabu likes this latency. Because the creditors will have
> more time to be aware of a fraudulent activity from issuer and existence
> of a cheating transaction in mempool, so they have more time to send and
> broad cast the GT to network. More latency, more chance in batch update.
> So more chance for miners to face two or three transactions which are
> using same UTXO but sending to different addresses and paying different
> fees.
> More latency increases the chance of putting the higher-fee-payer
> transaction in next block.
Actually it's the opposite, if pools updated their templates every second
the GT transaction could almost immediately replace the fraudulent transaction,
however due to the batch updating if the fraudulent transaction ended up
in a template it could take a significant amount of time for it to be purged
from all the mining pool templates, no matter the fee difference.
Ultimately this means that one should always expect miners to mine the
first seen transaction for a significant period of time, with no guarantees
that it would be replaced.
>
> Regards
> Raymo
>
>
> On 2021-06-28 08:23, James Hilliard wrote:
> > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>
> >> Hi ZmnSCPxj,
> >>
> >> Why you get the signal “trust the Gazin wallet”?
> >> Sabu is a protocol and the Gazin wallet will be an implementation of
> >> that protocol. We will implement it in react-native language to support
> >> both Android and iPhone. Of course it will be open source and GPL3.
> >> Here is the repository and yet is empty :)
> >> https://github.com/raymaot/Gazin
> >>
> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> >> will be far better than Lightning.
> >> Can’t you see the fact that in Sabu you do not need open and close
> >> channels ever? Can you imagine only this feature how dramatically
> >> decrease the transactions cost and how increase the distribution of
> >> nodes and improve privacy level? it makes every mobile wallet act like a
> >> lightning network.
> >> Did you note the fact that in Sabu protocol there is no routing? And the
> >> only people knew about a transaction are issuer and creditor? No one
> >> else won’t be aware of transactions and million transactions per second
> >> can be sent and received and repeal dynamically without any footprint on
> >> any DLT?
> >>
> >> The English is not my mother language and probably my paper is not a
> >> smooth and easy to read paper, but these are not good excuse to not even
> >> reading a technical paper carefully and before understanding it or at
> >> least trying to understanding it start to complaining.
> >
> > Considering that you have not effectively addressed any of the inaccurate
> > assumptions made regarding how mining works that I pointed out earlier
> > I assume your proposal is not viable in practice.
> >
> > See:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
> >
> >>
> >> > All the benefits your scheme claims, are derived from the trust assumption
> >> No, All the benefits my scheme claims, are derived from economically
> >> rational decision of both issuer and creditors.
> >>
> >> Regards
> >> Raymo
> >>
> >>
> >>
> >> On 2021-06-28 05:20, ZmnSCPxj wrote:
> >> > Good morning Raymo,
> >> >
> >> >>
> >> >> It looks you already missed the entire design of Sabu and its
> >> >> restrictions. First of all, the Gazin wallet always controls the Sabu
> >> >> restrictions for every transaction in order to consider it as a valid
> >> >> transaction in a valid deal. That is, the creditor wallet controls the
> >> >> MT and GT in first place.
> >> >
> >> > Stop right there.
> >> >
> >> > From the above, what I get is, "trust the Gazin wallet".
> >> > Thus, the suggestion to just use Coinbase.
> >> > At least it has existed longer and has more current users that trust
> >> > it, rather than this Gazin thing.
> >> >
> >> >
> >> > Is Gazin open-source?
> >> >
> >> > * If Gazin is open-source, I could download the source code, make a
> >> > local copy that gives me a separate copy of the keys, and use the keys
> >> > to sign any transaction I want.
> >> > * If Gazin is not open-source, then why should I trust the Gazin
> >> > wallet until my incoming funds to an open-source wallet I control have
> >> > been confirmed deeply?
> >> >
> >> > Lightning is still superior because:
> >> >
> >> > * It can be open-sourced completely and even though I have keys to my
> >> > onchain funds, I *still* cannot steal the funds of my counterparty.
> >> > * Even if I connect my open-source node to a node with a closed-source
> >> > implementation, I know I can rely on receives from that node without
> >> > waiting for the transaction to be confirmed deeply.
> >> >
> >> >
> >> > All the benefits your scheme claims, are derived from the trust
> >> > assumption, which is uninteresting, we already have those, they are
> >> > called custodial wallets.
> >> > Lightning allows for non-custodiality while achieving high global TPS
> >> > and low fees.
> >> > And a central idea of Lightning is the requirement to use an n-of-n to
> >> > form smaller sub-moneys from the global money.
> >> >
> >> > Regards,
> >> > ZmnSCPxj
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 6:29 ` raymo
2021-06-28 8:23 ` James Hilliard
@ 2021-06-28 15:28 ` ZmnSCPxj
2021-06-28 16:58 ` raymo
2021-06-28 17:29 ` Tao Effect
1 sibling, 2 replies; 41+ messages in thread
From: ZmnSCPxj @ 2021-06-28 15:28 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
Good morning Raymo,
> Hi ZmnSCPxj,
>
> Why you get the signal “trust the Gazin wallet”?
> Sabu is a protocol and the Gazin wallet will be an implementation of
> that protocol. We will implement it in react-native language to support
> both Android and iPhone. Of course it will be open source and GPL3.
> Here is the repository and yet is empty :)
> https://github.com/raymaot/Gazin
>
> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> will be far better than Lightning.
> Can’t you see the fact that in Sabu you do not need open and close
> channels ever? Can you imagine only this feature how dramatically
> decrease the transactions cost and how increase the distribution of
> nodes and improve privacy level? it makes every mobile wallet act like a
> lightning network.
> Did you note the fact that in Sabu protocol there is no routing? And the
> only people knew about a transaction are issuer and creditor? No one
> else won’t be aware of transactions and million transactions per second
> can be sent and received and repeal dynamically without any footprint on
> any DLT?
>
> The English is not my mother language and probably my paper is not a
> smooth and easy to read paper, but these are not good excuse to not even
> reading a technical paper carefully and before understanding it or at
> least trying to understanding it start to complaining.
What prevents the creditor from signing a transaction that is neither a valid MT nor a GT?
Nothing.
In Lightning, sure one side can sign a transaction that is not a valid commitment transaction, but good luck getting the other side to *also* sign the transaction; it will not.
Thus, you need n-of-n.
1-of-1 is simply not secure, full stop, you need to redesign the whole thing to use *at least* 2-of-2.
At which point you will have reinvented Lightning.
Otherwise, you are simply trusting that the wallet is implemented correctly, and in particular, that any creditor will not simply insert code in your open-source software to sign invalid transactions.
With a 1-of-1, any invalid-in-Sabu transaction can still be valid in the Bitcoin blockchain layer, thus the scheme is simply insecure.
Features are meaningless without this kind of basic trust-minimization security.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 11:28 ` James Hilliard
@ 2021-06-28 16:33 ` raymo
0 siblings, 0 replies; 41+ messages in thread
From: raymo @ 2021-06-28 16:33 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Protocol Discussion
Hi James,
> There's only one practical approach I'm aware of for miners to actually
> do this, and that would be to effectively make mining centralized.
> So I would highly discourage this sort of policy when it comes to mining.
I do not know about the approach you talking about it, but my solution
is not centralized at all. In Sabu proposal/architecture you can find
the doc-watchers network. It will be a torrent-like network where nodes
just gossip the very light information about used UTXOs in Sabu
protocol. All nodes will receive information and flood it to other
nodes. So, all nodes just mirror same information.
Two types of information are transferring through this peer-to-peer
doc-watcher network.
One is a very minimal record history of the UTXOs and a Merkle root of
proper Sabu transactions. This information will be used by mobile wallet
to be ensure issuer didn’t promise same UTXO to different creditors.
The second data type are moving through doc-watchers nodes are signed
UTXOs in order to signal to miners the fact that this UTXO is promised
to some creditors. So, miners won’t allow this UTXO to be used in other
ways to promise. In order to release (un-pledge) this UTXO the issuer
has to sign it again alongside a release request.
It is roughly what I suppose to be implemented and be respected by
miners in future. It wouldn’t be centralized unless you believe torrent
is centralized. Miners can/will control UTXOs status (in sense of is
promised to someone or not) before putting them in batch template.
> Miners regularly change block headers, and if they don't broadcast the
> transactions there wouldn't really be a time limit, so even a relatively small
> miner would be able to stealthily mine the transactions given enough time.
It means a miner at least every 10 minutes has to change the header and
re-try to solve the puzzle. Yes, a miner or a mining pool can stealthily
mine transactions given enough time. And we already knew time of solving
a puzzle is almost random. So “maybe” the small miner is enough lucky to
find a block full of fraudulent transaction. But the question is; this
effort to fraud, how much more economically beneficial than
participation in the healthy chain will be? The answer will tell us the
feasibility of Sabu protocol.
There is another protection that won't let the worker and creditor to
mine stealthily a particular UTXO set for unlimited time.
please read the appendix "V: Recycling UTXOs" for more details.
> Why would they need to solve the block within 10 minutes?
You are right, they are not forced to solve it in 10 minutes but
definitely they have to change the header every 10 minutes. Otherwise,
they would end up in mining an orphan block which has no sense.
Although it is not linear, but I used to believe changing block header
every 10 minutes will reduce efficiency and chance of solving puzzle
dramatically.
> All that matters is if that extra is more than they would otherwise get.
Yes, while it is true, but it is not enough. We need numbers and
calculation to find if this kind of attack is possible? And how much is
the possibility? And…
An attack with 0.01% of success is obviously a failed plan and no one
consider it as a threat. Although even this small threat will be resolve
by the mentioned BIP absolutely.
About the timing details.
You are right. The less batch update time means more chance to
fraudulent transaction replaced by the GT transaction.
BTW even this scenario would be improved by suggested BIP
implementation, since the fraudulent transaction won’t be in batch
template at all.
Best
On 2021-06-28 11:28, James Hilliard wrote:
> On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup•net> wrote:
>>
>>
>> Hi James,
>> Sorry for not responding in detail.
>> So, lets jump in the critiques.
>>
>> > You're making the assumption that miners won't build on top of a block
>> with transactions they have not seen before or transactions that may
>> contain double spends of unconfirmed inputs
>> No, it is a wish. I hope in future miners consider this rule as well.
>
> There's only one practical approach I'm aware of for miners to actually
> do this, and that would be to effectively make mining centralized.
> So I would highly discourage this sort of policy when it comes to mining.
>
>> But for now, I absolutely do not count on this restriction. So, miner
>> can/will accept a valid block which contains some valid transactions
>> which they didn’t aware of those transactions in advance.
>
> Mempools among miners are generally not fully in sync with each other,
> rejecting valid blocks due to disagreements over which transactions were
> broadcast would destabilize the network as you'd get a bunch of network
> forks.
>
>> In order to explain how economically this won’t happened, I have to
>> refer you to the fact that a conspiracy between a miner(mining pool) and
>> a group of issuers to mine a block full of cheating transaction will
>> makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
>> now). The 1.2 is coming from average(max) 6,000 transaction per block *
>> max 20K Satoshi cheating benefit for each promised used UTXO in a
>> debt-doc(transaction).
>
> But there's no risk really for a miner to choose the most profitable
> transactions to mine as long as they are valid per the network rules,
> that is unless you make mining fully centralized.
>
>> In order to achieve this conspiracy, the mining pool has to mine the
>> block in stealth, lonely and without broadcasting any of transactions to
>> Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
>> they have to change the block header and restart again. After all, if
>> they succeed, they have to divide this extra dirty 1.2 BTC in between. I
>
> Miners regularly change block headers, and if they don't broadcast the
> transactions there wouldn't really be a time limit, so even a relatively small
> miner would be able to stealthily mine the transactions given enough time.
>
>>
>>
>> I am not expert in mining pool calculations; you may help me to answer
>> these questions?
>>
>> Consider these given facts:
>>
>> More hashrate = more success chance.
>> More hashrate = more electric cost = less profit per each participator
>> There is a minimum hashrate to have a minimum chance to solve the puzzle
>> in next 10 minutes, otherwise it doesn't make sense to participate in an
>> activity that doesn't fit the minimum hope.
>
> Why would they need to solve the block within 10 minutes?
>
>> How much is this minimum hashrate?
>
> I don't think there is a minimum.
>
>> How much costs this hashrate?
>
> Miners just use pools to reduce variance, there isn't a set minimum size to
> solo mine, only how much variance the miner can tolerate.
>
>> Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
>> be economically cost effective (risk to reward) to dedicate your
>> hashrate to mine this block? I am not sure. But if you show me the
>> opposite by facts and numbers, I will highly appreciate you.
>
> All that matters is if that extra is more than they would otherwise get.
>
>>
>> > What would this BIP look like?
>> > We suppose the miners always control transactions with doc-watchers
>> As I told before, these assumptions are my wishes and I never relayed on
>> these wishes. These are for future. For now, I just count on the
>> calculation that asked you to help.
>
> The reason I ask is because I don't think this is possible to do
> without massively
> centralizing mining.
>
>>
>> > there can be significant latency between the time a transaction is
>> actually broadcast and hits the miners mempool and the time the miners
>> actually switch to mining on top it
>>
>> It is great. Although this latency could be lesser (in case of empty
>> mempools), but Sabu likes this latency. Because the creditors will have
>> more time to be aware of a fraudulent activity from issuer and existence
>> of a cheating transaction in mempool, so they have more time to send and
>> broad cast the GT to network. More latency, more chance in batch update.
>> So more chance for miners to face two or three transactions which are
>> using same UTXO but sending to different addresses and paying different
>> fees.
>> More latency increases the chance of putting the higher-fee-payer
>> transaction in next block.
>
> Actually it's the opposite, if pools updated their templates every second
> the GT transaction could almost immediately replace the fraudulent transaction,
> however due to the batch updating if the fraudulent transaction ended up
> in a template it could take a significant amount of time for it to be purged
> from all the mining pool templates, no matter the fee difference.
>
> Ultimately this means that one should always expect miners to mine the
> first seen transaction for a significant period of time, with no guarantees
> that it would be replaced.
>
>>
>> Regards
>> Raymo
>>
>>
>> On 2021-06-28 08:23, James Hilliard wrote:
>> > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >>
>> >> Hi ZmnSCPxj,
>> >>
>> >> Why you get the signal “trust the Gazin wallet”?
>> >> Sabu is a protocol and the Gazin wallet will be an implementation of
>> >> that protocol. We will implement it in react-native language to support
>> >> both Android and iPhone. Of course it will be open source and GPL3.
>> >> Here is the repository and yet is empty :)
>> >> https://github.com/raymaot/Gazin
>> >>
>> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu
>> >> will be far better than Lightning.
>> >> Can’t you see the fact that in Sabu you do not need open and close
>> >> channels ever? Can you imagine only this feature how dramatically
>> >> decrease the transactions cost and how increase the distribution of
>> >> nodes and improve privacy level? it makes every mobile wallet act like a
>> >> lightning network.
>> >> Did you note the fact that in Sabu protocol there is no routing? And the
>> >> only people knew about a transaction are issuer and creditor? No one
>> >> else won’t be aware of transactions and million transactions per second
>> >> can be sent and received and repeal dynamically without any footprint on
>> >> any DLT?
>> >>
>> >> The English is not my mother language and probably my paper is not a
>> >> smooth and easy to read paper, but these are not good excuse to not even
>> >> reading a technical paper carefully and before understanding it or at
>> >> least trying to understanding it start to complaining.
>> >
>> > Considering that you have not effectively addressed any of the inaccurate
>> > assumptions made regarding how mining works that I pointed out earlier
>> > I assume your proposal is not viable in practice.
>> >
>> > See:
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
>> >
>> >>
>> >> > All the benefits your scheme claims, are derived from the trust assumption
>> >> No, All the benefits my scheme claims, are derived from economically
>> >> rational decision of both issuer and creditors.
>> >>
>> >> Regards
>> >> Raymo
>> >>
>> >>
>> >>
>> >> On 2021-06-28 05:20, ZmnSCPxj wrote:
>> >> > Good morning Raymo,
>> >> >
>> >> >>
>> >> >> It looks you already missed the entire design of Sabu and its
>> >> >> restrictions. First of all, the Gazin wallet always controls the Sabu
>> >> >> restrictions for every transaction in order to consider it as a valid
>> >> >> transaction in a valid deal. That is, the creditor wallet controls the
>> >> >> MT and GT in first place.
>> >> >
>> >> > Stop right there.
>> >> >
>> >> > From the above, what I get is, "trust the Gazin wallet".
>> >> > Thus, the suggestion to just use Coinbase.
>> >> > At least it has existed longer and has more current users that trust
>> >> > it, rather than this Gazin thing.
>> >> >
>> >> >
>> >> > Is Gazin open-source?
>> >> >
>> >> > * If Gazin is open-source, I could download the source code, make a
>> >> > local copy that gives me a separate copy of the keys, and use the keys
>> >> > to sign any transaction I want.
>> >> > * If Gazin is not open-source, then why should I trust the Gazin
>> >> > wallet until my incoming funds to an open-source wallet I control have
>> >> > been confirmed deeply?
>> >> >
>> >> > Lightning is still superior because:
>> >> >
>> >> > * It can be open-sourced completely and even though I have keys to my
>> >> > onchain funds, I *still* cannot steal the funds of my counterparty.
>> >> > * Even if I connect my open-source node to a node with a closed-source
>> >> > implementation, I know I can rely on receives from that node without
>> >> > waiting for the transaction to be confirmed deeply.
>> >> >
>> >> >
>> >> > All the benefits your scheme claims, are derived from the trust
>> >> > assumption, which is uninteresting, we already have those, they are
>> >> > called custodial wallets.
>> >> > Lightning allows for non-custodiality while achieving high global TPS
>> >> > and low fees.
>> >> > And a central idea of Lightning is the requirement to use an n-of-n to
>> >> > form smaller sub-moneys from the global money.
>> >> >
>> >> > Regards,
>> >> > ZmnSCPxj
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists•linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 15:28 ` ZmnSCPxj
@ 2021-06-28 16:58 ` raymo
2021-06-28 17:58 ` Alex Schoof
2021-06-28 17:29 ` Tao Effect
1 sibling, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-28 16:58 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
> What prevents the creditor from signing a transaction that is neither a valid MT nor a GT?
Please stop comparing Sabu and Lightning. Otherwise, it won't let you
true understanding of Sabu.
In Sabu protocol, only the issuer (the UTXO owner) can sign the
transaction and decide how much money goes to whom. The engaged UTXO(s)
belonged to issuer and the creditor never put UTXO in transaction, thus
never can sign the transaction because he has no ownership on the used
UTXOs.
As I already wrote in paper, the issuer creates and signs a transaction
and delivers it to creditor(s). If a creditor intends to send all or
part of his money to another person (AKA spending his money), he will
ask for a new signed transaction from issuer, in which a part of his
credit will transfer to another creditor.
The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of
doc-watchers which maybe it was the cause you always compare it to
Lightning.
I am not presenting lightning neither condemning it.
I am presenting Sabu protocol.
Please let concentrate on how Sabu works or not works.
On 2021-06-28 15:28, ZmnSCPxj wrote:
> Good morning Raymo,
>
>> Hi ZmnSCPxj,
>>
>> Why you get the signal “trust the Gazin wallet”?
>> Sabu is a protocol and the Gazin wallet will be an implementation of
>> that protocol. We will implement it in react-native language to support
>> both Android and iPhone. Of course it will be open source and GPL3.
>> Here is the repository and yet is empty :)
>> https://github.com/raymaot/Gazin
>>
>> I wonder why you do not look carefully into the proposal! IMHO the Sabu
>> will be far better than Lightning.
>> Can’t you see the fact that in Sabu you do not need open and close
>> channels ever? Can you imagine only this feature how dramatically
>> decrease the transactions cost and how increase the distribution of
>> nodes and improve privacy level? it makes every mobile wallet act like a
>> lightning network.
>> Did you note the fact that in Sabu protocol there is no routing? And the
>> only people knew about a transaction are issuer and creditor? No one
>> else won’t be aware of transactions and million transactions per second
>> can be sent and received and repeal dynamically without any footprint on
>> any DLT?
>>
>> The English is not my mother language and probably my paper is not a
>> smooth and easy to read paper, but these are not good excuse to not even
>> reading a technical paper carefully and before understanding it or at
>> least trying to understanding it start to complaining.
>
>
> What prevents the creditor from signing a transaction that is neither
> a valid MT nor a GT?
>
> Nothing.
>
> In Lightning, sure one side can sign a transaction that is not a valid
> commitment transaction, but good luck getting the other side to *also*
> sign the transaction; it will not.
> Thus, you need n-of-n.
>
> 1-of-1 is simply not secure, full stop, you need to redesign the whole
> thing to use *at least* 2-of-2.
> At which point you will have reinvented Lightning.
>
> Otherwise, you are simply trusting that the wallet is implemented
> correctly, and in particular, that any creditor will not simply insert
> code in your open-source software to sign invalid transactions.
>
> With a 1-of-1, any invalid-in-Sabu transaction can still be valid in
> the Bitcoin blockchain layer, thus the scheme is simply insecure.
>
> Features are meaningless without this kind of basic trust-minimization security.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 15:28 ` ZmnSCPxj
2021-06-28 16:58 ` raymo
@ 2021-06-28 17:29 ` Tao Effect
2021-06-28 17:38 ` raymo
1 sibling, 1 reply; 41+ messages in thread
From: Tao Effect @ 2021-06-28 17:29 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hi ZmnSCPxj & Raymo,
> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Good morning Raymo,
>
>> Hi ZmnSCPxj,
>> […]
> What prevents the creditor from signing a transaction that is neither a valid MT nor a GT?
>
> Nothing.
How would the creditor create such a transaction? They need the issuer’s private key, so they can’t create it? Am I misunderstanding the scenario you’re describing? If so could you give a more detailed description?
Cheers,
Greg
[-- Attachment #2: Type: text/html, Size: 1274 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 17:29 ` Tao Effect
@ 2021-06-28 17:38 ` raymo
2021-06-28 18:05 ` Ricardo Filipe
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-28 17:38 UTC (permalink / raw)
To: Tao Effect; +Cc: Bitcoin Protocol Discussion
Hi Greg,
You are right, the whole scenario is:
there is an issuer which own a UTXO
issuers get fiat money or goods or services from creditor in exchange of
a transaction.
the transactions are intended to circulate in Sabu protocol instead of
sending to Bitcoin network.
creditor can not sign the transaction at all. instead he can ask issuer
to change the balances (transaction outputs) and transfer some of his
money to other creditor...
here is complete paper to read it carefully:
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
Cheers
Raymo
On 2021-06-28 17:29, Tao Effect wrote:
> Hi ZmnSCPxj & Raymo,
>
>> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Good morning Raymo,
>>
>>> Hi ZmnSCPxj,
>>
>>> […]
>> What prevents the creditor from signing a transaction that is
>> neither a valid MT nor a GT?
>>
>> Nothing.
>
> How would the creditor create such a transaction? They need the
> issuer’s private key, so they can’t create it? Am I
> misunderstanding the scenario you’re describing? If so could you
> give a more detailed description?
>
> Cheers,
> Greg
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 16:58 ` raymo
@ 2021-06-28 17:58 ` Alex Schoof
2021-06-28 19:07 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Alex Schoof @ 2021-06-28 17:58 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, raymo
[-- Attachment #1: Type: text/plain, Size: 5344 bytes --]
Hey Raymo,
Here’s a scenario:
Alice has one UTXO.
Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives whatever
goods and services to Alice.
Alice then goes and spends that UTXO to Charlie with a higher fee than the
GT she sent to Bob. Charlie has no idea that Bob exists, because he gets a
valid UTXO. Bob can try to publish the GT, but if Alice crafts the fees
right, the TX to Charlie will be confirmed first. Alice now has goods from
both Bob and Charlie, and has only paid one of them. She has is able to
double spend because: (1) the gossip network you describe for sabu only
protects people if everyone is on sabu and playing by the rules, it does
not prevent spending outside of sabu; and (2) there is nothing encumbering
the onchain UTXO and preventing it from being spent outside of a sabu
payment.
The reason people keep brining up Lightning is because Lightning solves
this problem by having a channel-open involve locking funds in a 2-of-2
multisig, preventing them from being spent outside of lightning until the
channel is torn down.
If there is nothing stopping someone from spending onchain funds outside of
the context of your system, then your system does not prevent double spends.
Hope that explanation helps.
Alex
On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> > What prevents the creditor from signing a transaction that is neither a
> valid MT nor a GT?
> Please stop comparing Sabu and Lightning. Otherwise, it won't let you
> true understanding of Sabu.
> In Sabu protocol, only the issuer (the UTXO owner) can sign the
> transaction and decide how much money goes to whom. The engaged UTXO(s)
> belonged to issuer and the creditor never put UTXO in transaction, thus
> never can sign the transaction because he has no ownership on the used
> UTXOs.
> As I already wrote in paper, the issuer creates and signs a transaction
> and delivers it to creditor(s). If a creditor intends to send all or
> part of his money to another person (AKA spending his money), he will
> ask for a new signed transaction from issuer, in which a part of his
> credit will transfer to another creditor.
>
> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of
> doc-watchers which maybe it was the cause you always compare it to
> Lightning.
> I am not presenting lightning neither condemning it.
> I am presenting Sabu protocol.
> Please let concentrate on how Sabu works or not works.
>
>
>
> On 2021-06-28 15:28, ZmnSCPxj wrote:
> > Good morning Raymo,
> >
> >> Hi ZmnSCPxj,
> >>
> >> Why you get the signal “trust the Gazin wallet”?
> >> Sabu is a protocol and the Gazin wallet will be an implementation of
> >> that protocol. We will implement it in react-native language to support
> >> both Android and iPhone. Of course it will be open source and GPL3.
> >> Here is the repository and yet is empty :)
> >> https://github.com/raymaot/Gazin
> >>
> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> >> will be far better than Lightning.
> >> Can’t you see the fact that in Sabu you do not need open and close
> >> channels ever? Can you imagine only this feature how dramatically
> >> decrease the transactions cost and how increase the distribution of
> >> nodes and improve privacy level? it makes every mobile wallet act like a
> >> lightning network.
> >> Did you note the fact that in Sabu protocol there is no routing? And the
> >> only people knew about a transaction are issuer and creditor? No one
> >> else won’t be aware of transactions and million transactions per second
> >> can be sent and received and repeal dynamically without any footprint on
> >> any DLT?
> >>
> >> The English is not my mother language and probably my paper is not a
> >> smooth and easy to read paper, but these are not good excuse to not even
> >> reading a technical paper carefully and before understanding it or at
> >> least trying to understanding it start to complaining.
> >
> >
> > What prevents the creditor from signing a transaction that is neither
> > a valid MT nor a GT?
> >
> > Nothing.
> >
> > In Lightning, sure one side can sign a transaction that is not a valid
> > commitment transaction, but good luck getting the other side to *also*
> > sign the transaction; it will not.
> > Thus, you need n-of-n.
> >
> > 1-of-1 is simply not secure, full stop, you need to redesign the whole
> > thing to use *at least* 2-of-2.
> > At which point you will have reinvented Lightning.
> >
> > Otherwise, you are simply trusting that the wallet is implemented
> > correctly, and in particular, that any creditor will not simply insert
> > code in your open-source software to sign invalid transactions.
> >
> > With a 1-of-1, any invalid-in-Sabu transaction can still be valid in
> > the Bitcoin blockchain layer, thus the scheme is simply insecure.
> >
> > Features are meaningless without this kind of basic trust-minimization
> security.
> >
> > Regards,
> > ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
[-- Attachment #2: Type: text/html, Size: 6757 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 17:38 ` raymo
@ 2021-06-28 18:05 ` Ricardo Filipe
0 siblings, 0 replies; 41+ messages in thread
From: Ricardo Filipe @ 2021-06-28 18:05 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
I believe Zman meant issuer.
raymo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> escreveu
no dia segunda, 28/06/2021 à(s) 18:45:
>
> Hi Greg,
> You are right, the whole scenario is:
> there is an issuer which own a UTXO
> issuers get fiat money or goods or services from creditor in exchange of
> a transaction.
> the transactions are intended to circulate in Sabu protocol instead of
> sending to Bitcoin network.
> creditor can not sign the transaction at all. instead he can ask issuer
> to change the balances (transaction outputs) and transfer some of his
> money to other creditor...
> here is complete paper to read it carefully:
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Cheers
> Raymo
>
>
> On 2021-06-28 17:29, Tao Effect wrote:
> > Hi ZmnSCPxj & Raymo,
> >
> >> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev
> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>
> >> Good morning Raymo,
> >>
> >>> Hi ZmnSCPxj,
> >>
> >>> […]
> >> What prevents the creditor from signing a transaction that is
> >> neither a valid MT nor a GT?
> >>
> >> Nothing.
> >
> > How would the creditor create such a transaction? They need the
> > issuer’s private key, so they can’t create it? Am I
> > misunderstanding the scenario you’re describing? If so could you
> > give a more detailed description?
> >
> > Cheers,
> > Greg
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 17:58 ` Alex Schoof
@ 2021-06-28 19:07 ` raymo
2021-06-29 21:42 ` ZmnSCPxj
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-06-28 19:07 UTC (permalink / raw)
To: Alex Schoof; +Cc: Bitcoin Protocol Discussion
Hey Alex,
Your scenario works perfectly unless we put some restrictions on
accepting transaction by creditor (in our case Bob).
These are restrictions:
Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
transaction input.
Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
regardless of transaction length or input/output amounts.
Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
6,000 remined fee must be paid by she and Bob in proportion to their
outputs amounts)
Alice can issue a transaction the has maximum 20,000 outputs for
creditors (Bob and others).
The rest (if exist) is change back to Alice address.
The GT is formed based on MT.
Bob considers a transaction couple (MT, GT) valid only if they respect
these rules.
Let’s put it in practice using some numbers (although you can find more
detailed explanation in paper).
The MT would be like that:
Input: 40,000 Satoshi
Outputs:
Bob: 20,000
BTC-fee: 10,000
Change back to Alice: 10,000
Based on this MT the GT will be
Input: 40,000 Satoshi
Outputs:
Bob: 20,000 – 20,000*70% = 6,000
BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change
back) = 25,500
Change back to Alice: 10,000 – 10,000*15% = 8,500
Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
to put his fraudulent transaction instead the GT in next block.
Alice already got 20,000 Sat profit from Bob. Now she can earn another
14,999 Sat profit from Charlie because of same UTXO worth 40,000
Satoshi.
Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
or services.
Is she a winner?
I am not sure!
What do you think?
By the way, we can tune the kI and kC coefficients to reduce this 34,999
to 30,000 or even less.
In this case Alice rationally prefers to not cheat on Bob.
The complementary protection would be the mentioned BIP for miners.
That BIP not only solve all these .01% risks but also would be a huge
improvement of adapting smart contracts (and consequently DeFi) on top
of current Bitcoin with lowest cost, but it is another story for another
day.
Raymo
On 2021-06-28 17:58, Alex Schoof wrote:
> Hey Raymo,
>
> Here’s a scenario:
>
> Alice has one UTXO.
>
> Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives
> whatever goods and services to Alice.
>
> Alice then goes and spends that UTXO to Charlie with a higher fee than
> the GT she sent to Bob. Charlie has no idea that Bob exists, because
> he gets a valid UTXO. Bob can try to publish the GT, but if Alice
> crafts the fees right, the TX to Charlie will be confirmed first.
> Alice now has goods from both Bob and Charlie, and has only paid one
> of them. She has is able to double spend because: (1) the gossip
> network you describe for sabu only protects people if everyone is on
> sabu and playing by the rules, it does not prevent spending outside of
> sabu; and (2) there is nothing encumbering the onchain UTXO and
> preventing it from being spent outside of a sabu payment.
>
> The reason people keep brining up Lightning is because Lightning
> solves this problem by having a channel-open involve locking funds in
> a 2-of-2 multisig, preventing them from being spent outside of
> lightning until the channel is torn down.
>
> If there is nothing stopping someone from spending onchain funds
> outside of the context of your system, then your system does not
> prevent double spends.
>
> Hope that explanation helps.
>
> Alex
>
> On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>> What prevents the creditor from signing a transaction that is
>> neither a valid MT nor a GT?
>> Please stop comparing Sabu and Lightning. Otherwise, it won't let
>> you
>> true understanding of Sabu.
>> In Sabu protocol, only the issuer (the UTXO owner) can sign the
>> transaction and decide how much money goes to whom. The engaged
>> UTXO(s)
>> belonged to issuer and the creditor never put UTXO in transaction,
>> thus
>> never can sign the transaction because he has no ownership on the
>> used
>> UTXOs.
>> As I already wrote in paper, the issuer creates and signs a
>> transaction
>> and delivers it to creditor(s). If a creditor intends to send all or
>> part of his money to another person (AKA spending his money), he
>> will
>> ask for a new signed transaction from issuer, in which a part of his
>> credit will transfer to another creditor.
>>
>> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network
>> of
>> doc-watchers which maybe it was the cause you always compare it to
>> Lightning.
>> I am not presenting lightning neither condemning it.
>> I am presenting Sabu protocol.
>> Please let concentrate on how Sabu works or not works.
>>
>> On 2021-06-28 15:28, ZmnSCPxj wrote:
>>> Good morning Raymo,
>>>
>>>> Hi ZmnSCPxj,
>>>>
>>>> Why you get the signal “trust the Gazin wallet”?
>>>> Sabu is a protocol and the Gazin wallet will be an implementation
>> of
>>>> that protocol. We will implement it in react-native language to
>> support
>>>> both Android and iPhone. Of course it will be open source and
>> GPL3.
>>>> Here is the repository and yet is empty :)
>>>> https://github.com/raymaot/Gazin
>>>>
>>>> I wonder why you do not look carefully into the proposal! IMHO
>> the Sabu
>>>> will be far better than Lightning.
>>>> Can’t you see the fact that in Sabu you do not need open and
>> close
>>>> channels ever? Can you imagine only this feature how dramatically
>>>> decrease the transactions cost and how increase the distribution
>> of
>>>> nodes and improve privacy level? it makes every mobile wallet act
>> like a
>>>> lightning network.
>>>> Did you note the fact that in Sabu protocol there is no routing?
>> And the
>>>> only people knew about a transaction are issuer and creditor? No
>> one
>>>> else won’t be aware of transactions and million transactions
>> per second
>>>> can be sent and received and repeal dynamically without any
>> footprint on
>>>> any DLT?
>>>>
>>>> The English is not my mother language and probably my paper is
>> not a
>>>> smooth and easy to read paper, but these are not good excuse to
>> not even
>>>> reading a technical paper carefully and before understanding it
>> or at
>>>> least trying to understanding it start to complaining.
>>>
>>>
>>> What prevents the creditor from signing a transaction that is
>> neither
>>> a valid MT nor a GT?
>>>
>>> Nothing.
>>>
>>> In Lightning, sure one side can sign a transaction that is not a
>> valid
>>> commitment transaction, but good luck getting the other side to
>> *also*
>>> sign the transaction; it will not.
>>> Thus, you need n-of-n.
>>>
>>> 1-of-1 is simply not secure, full stop, you need to redesign the
>> whole
>>> thing to use *at least* 2-of-2.
>>> At which point you will have reinvented Lightning.
>>>
>>> Otherwise, you are simply trusting that the wallet is implemented
>>> correctly, and in particular, that any creditor will not simply
>> insert
>>> code in your open-source software to sign invalid transactions.
>>>
>>> With a 1-of-1, any invalid-in-Sabu transaction can still be valid
>> in
>>> the Bitcoin blockchain layer, thus the scheme is simply insecure.
>>>
>>> Features are meaningless without this kind of basic
>> trust-minimization security.
>>>
>>> Regards,
>>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> --
>
> Alex Schoof
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-28 19:07 ` raymo
@ 2021-06-29 21:42 ` ZmnSCPxj
2021-06-30 12:21 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: ZmnSCPxj @ 2021-06-29 21:42 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
Good morning Raymo,
> Hey Alex,
>
> Your scenario works perfectly unless we put some restrictions on
> accepting transaction by creditor (in our case Bob).
> These are restrictions:
> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
> transaction input.
> Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
> regardless of transaction length or input/output amounts.
> Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
> 6,000 remined fee must be paid by she and Bob in proportion to their
> outputs amounts)
> Alice can issue a transaction the has maximum 20,000 outputs for
> creditors (Bob and others).
> The rest (if exist) is change back to Alice address.
> The GT is formed based on MT.
> Bob considers a transaction couple (MT, GT) valid only if they respect
> these rules.
>
> Let’s put it in practice using some numbers (although you can find more
> detailed explanation in paper).
>
> The MT would be like that:
> Input: 40,000 Satoshi
> Outputs:
> Bob: 20,000
> BTC-fee: 10,000
> Change back to Alice: 10,000
>
> Based on this MT the GT will be
> Input: 40,000 Satoshi
> Outputs:
> Bob: 20,000 – 20,00070% = 6,000
> BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change
> back) = 25,500
> Change back to Alice: 10,000 – 10,00015% = 8,500
>
> Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
> pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
> to put his fraudulent transaction instead the GT in next block.
> Alice already got 20,000 Sat profit from Bob. Now she can earn another
> 14,999 Sat profit from Charlie because of same UTXO worth 40,000
> Satoshi.
> Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
> or services.
> Is she a winner?
> I am not sure!
> What do you think?
You assume here that Alice the issuer only has a single UTXO and that it creates a single transaction spending that UTXO.
It is helpful to remember that miners consider fee*rate*, but your security analysis is dependent on *fee* and not fee*rate*.
Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs to 1000 different Bobs?
Now, a GT has one input and two outputs.
1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 inputs, and 2000 outputs.
Now Alice the issuer, being the sole signer, can create a fraudulent transaction that spends all 1000 UTXOs and spends it to a single Carol output.
This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output.
Do you think Alice can get a better fee*rate* on that transaction while paying a lower aggregate *fee* than all the GTs combined?
Remember, you based your security analysis on Alice being forced to pay a larger *fee*, but neglect that miners judge transactions based on fee*rate*, which is subtly different and not what you are relying on.
I am sure that there exists some large enough number of UTXOs where a single aggregating fraudulent transaction will be far cheaper than the tons of little GTs your security analysis depends on.
This is why we do not use 1-of-1 signers in safe offchain protocols.
Not your keys, not your coins.
--
In addition, your analysis is based on assuming that miners are perfect rational beings of perfect rationality, ***and*** are omniscient.
In reality, miners possess bounded knowledge, i.e. they do not know everything.
Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction with lower feerate than the MT, then feed the rest of the network with a valid MT.
Because transactions propagate through the network but this propagation is ***not*** instantaneous, it is possible for the MT to reach the miners later than the fraudulent transaction.
In this window of time, a block may be mined that includes the fraudulent transaction, simply because the lucky miner never managed to hear of the correct MT.
This attack is essentially costless to Alice, especially for big enough transactions where mining fees are a negligible part of the payment.
This is why we do not use 1-of-1 signers in safe offchain protocols.
Not your keys, not your coins.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-29 21:42 ` ZmnSCPxj
@ 2021-06-30 12:21 ` raymo
0 siblings, 0 replies; 41+ messages in thread
From: raymo @ 2021-06-30 12:21 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Dear ZmnSCPxj
Thanks for dedicating time to read carefully the Sabu proposal and many
thanks for your accurate point. So, lets fix it.
I didn’t suppose Alice has only one UTXO, instead I expect every issuer
use hundreds or even millions UTXOs (for optimal benefit each worth
exactly 40,000 Satoshi) in Sabu protocol in order to earn notable
Sabu-transactions-fees daily.
Your scenario is correct and Alice can send a batch transaction which
has higher feeRate, but less fee amount comparing total fees of N number
of GT transaction.
It is true, the batch transaction will win the race and will go to next
block instead of N small GT transactions.
But Alice herself is not the winner, since she paid a huge transaction
fee to miner, while in honest acting didn’t have to pay at all.
Let’s show it by numbers.
Imagine Alice convinced some people to pay her money and accept the MT
and GT transactions in exchange.
Alice issued N transactions and delivered to these guys.
Till now Alice got money equal to N * Maximum debt per transaction,
which is 20,000 N.
A single GT length = length of Critical part of GT (named C) + length of
Redundant part of GT (named R)
Coefficient of Honesty benefits (called H) = C/R
The bigger H means less Redundant part, means less benefit in batch
transaction.
The worst H would be 1 or less than 1. I can guess H in Bitcoin
transaction is 4 or higher, but for now we take it 4. Probably you can
help us and tell what H is exactly.
The N GTs length = N * (C + R)
One batch transaction length = (N * C) + R
The GT feeRate = GTfee / (C + R)
The batch transaction feeRate = batchFee / ((N * C) + R)
We need to batch transaction feeRate be higher than each single GT
feeRate (more or less the feeRate for all GTs are same).
Thus
batchFee / ((N * C) + R) must be bigger or at least equal to GTfee / (C
+ R)
so,
batchFee / ((N * C) + R) >= GTfee / (C + R)
we already knew H = C/R then C = HR
after simplifying
batchFee >= (GTfee * ((N * H) + 1)) / (H + 1)
So, this is the minimum fee that Alice has to pay for her batch
transaction in order to compete with GTs feeRate.
Let’s put the numbers
From my previous example for @Alex Schoof, we already knew that the
GTfee is 25,500 Satoshi
H is 4 (please let me know what is more realistic number)
I think N in max exploitation is 10,000. If Alice takes entire block
space, she won’t be able to put more than 10,000 inputs in a single
transaction in one block.
So,
batchFee must be higher than (25,500 * ((10,000 * 4) + 1)) / (4 + 1)
batchFee must be higher than 2.04 Bitcoins. While if Alice was acting
honestly, she had to pay zero BTC-transaction-fee, since the Sabu
transactions are aimed to be circulated in Sabu network forever.
But how much benefit Alice got? We already knew that Alice had fooled
Some people by 10,000 transactions and got 10,000 transaction * 20,000
Max debt per transaction. She got 2 Bitcoins.
After all, she lost 0.04 BTC. She definitely is a loser, unless she has
conspiracy with miners which is another scenario and I already explained
it.
Note these facts:
H is higher than 4.
It is impossible to fit a batch transaction with 10,000 inputs and one
output in one block.
And after all we can simply hedge batch transaction benefits by fine
tuning the “maximum allowed debt per transaction”.
Finally, the complementary protection to cover 0.01% remind risk of
issuer irrationality, would be the BIPxxx “for flagging/unflagging
promised UTXOs” which is my suggestion.
It will be good for Sabu.
It will be good for adapting wide range of innovative smart contracts on
top of current Bitcoin with no risk and cost.
@James Hilliard
If it implemented wisely, never won't affect on network stability.
> your analysis is based on assuming that miners are perfect rational beings of perfect rationality,
> ***and*** are omniscient.
That’s not true! The proposal just assume miners are looking for more
profit.
The suggested BIPxxx “for flagging/unflagging promised UTXOs” (if
community accept it) would prepare a knowledge about promised UTXOs for
miner.
> Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction
> with lower feerate than the MT, then feed the rest of the network with a valid MT.
It is not important in what order Alice propagate which (MT, or whatever
transaction) to Bitcoin network.
The point is, before putting this transaction in next block, the
creditor wallet will be aware of this renege and will send the GT to
network.
The rest is miner’s decision to put transaction with higher fee rate to
next block.
> This attack is essentially costless to Alice,
> especially for big enough transactions where mining fees are a negligible part of the payment.
No, in Sabu we have not big payments. Each big payment must be managed
through N small transactions with each transaction max output less than
20,000 Satoshi.
Regards
Raymo
On 2021-06-29 21:42, ZmnSCPxj wrote:
> Good morning Raymo,
>
>> Hey Alex,
>>
>> Your scenario works perfectly unless we put some restrictions on
>> accepting transaction by creditor (in our case Bob).
>> These are restrictions:
>> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
>> transaction input.
>> Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
>> regardless of transaction length or input/output amounts.
>> Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
>> 6,000 remined fee must be paid by she and Bob in proportion to their
>> outputs amounts)
>> Alice can issue a transaction the has maximum 20,000 outputs for
>> creditors (Bob and others).
>> The rest (if exist) is change back to Alice address.
>> The GT is formed based on MT.
>> Bob considers a transaction couple (MT, GT) valid only if they respect
>> these rules.
>>
>> Let’s put it in practice using some numbers (although you can find more
>> detailed explanation in paper).
>>
>> The MT would be like that:
>> Input: 40,000 Satoshi
>> Outputs:
>> Bob: 20,000
>> BTC-fee: 10,000
>> Change back to Alice: 10,000
>>
>> Based on this MT the GT will be
>> Input: 40,000 Satoshi
>> Outputs:
>> Bob: 20,000 – 20,00070% = 6,000
>> BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change
>> back) = 25,500
>> Change back to Alice: 10,000 – 10,00015% = 8,500
>>
>> Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
>> pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
>> to put his fraudulent transaction instead the GT in next block.
>> Alice already got 20,000 Sat profit from Bob. Now she can earn another
>> 14,999 Sat profit from Charlie because of same UTXO worth 40,000
>> Satoshi.
>> Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
>> or services.
>> Is she a winner?
>> I am not sure!
>> What do you think?
>
> You assume here that Alice the issuer only has a single UTXO and that
> it creates a single transaction spending that UTXO.
>
> It is helpful to remember that miners consider fee*rate*, but your
> security analysis is dependent on *fee* and not fee*rate*.
>
> Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs
> to 1000 different Bobs?
>
> Now, a GT has one input and two outputs.
>
> 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on),
> 1000 inputs, and 2000 outputs.
>
> Now Alice the issuer, being the sole signer, can create a fraudulent
> transaction that spends all 1000 UTXOs and spends it to a single Carol
> output.
>
> This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output.
>
> Do you think Alice can get a better fee*rate* on that transaction
> while paying a lower aggregate *fee* than all the GTs combined?
> Remember, you based your security analysis on Alice being forced to
> pay a larger *fee*, but neglect that miners judge transactions based
> on fee*rate*, which is subtly different and not what you are relying
> on.
> I am sure that there exists some large enough number of UTXOs where a
> single aggregating fraudulent transaction will be far cheaper than the
> tons of little GTs your security analysis depends on.
>
> This is why we do not use 1-of-1 signers in safe offchain protocols.
> Not your keys, not your coins.
>
> --
>
> In addition, your analysis is based on assuming that miners are
> perfect rational beings of perfect rationality, ***and*** are
> omniscient.
>
> In reality, miners possess bounded knowledge, i.e. they do not know everything.
>
> Even if Alice is in possession of only a single UTXO, Alice can still
> feed miners a transaction with lower feerate than the MT, then feed
> the rest of the network with a valid MT.
> Because transactions propagate through the network but this
> propagation is ***not*** instantaneous, it is possible for the MT to
> reach the miners later than the fraudulent transaction.
> In this window of time, a block may be mined that includes the
> fraudulent transaction, simply because the lucky miner never managed
> to hear of the correct MT.
>
> This attack is essentially costless to Alice, especially for big
> enough transactions where mining fees are a negligible part of the
> payment.
>
> This is why we do not use 1-of-1 signers in safe offchain protocols.
> Not your keys, not your coins.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-06-22 18:20 ` Billy Tetrud
@ 2021-07-01 20:11 ` raymo
2021-07-01 20:49 ` Erik Aronesty
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-07-01 20:11 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
Hi Billy,
Sorry for late reply. Let’s jump in proposal.
> Some more information about the benefits of this approach vs alternatives (mainly lightning)
The most important different is unlike the lightning, in Sabu no one
have to open a channel and pay Bitcoin transaction fee, subsequently no
one has to close channel and pay another Bitcoin transaction fee. It is
the huge improvement since it drops the overhead cost of transactions.
So, it will be more convenience to trade under Sabu protocol.
In Sabu none of parties of a transaction are obliged to block money in
any kind of smart contract or any other m of n signature accounts
on-chain, so it provides more privacy.
Since Sabu protocol is designed to motivate people to circulate
transactions (AKA debt documents) in Sabu network, if every actor act
rationally no one will aware how much money transferred from who to
whom.
In case of fraudulent activity by issuer, the creditor will send
Guarantee Transaction (GT) to Bitcoin network in order to recapture the
part of his credit. So, in this case the transaction is literally
recorded on bitcoin blockchain.
There is only one another reason to recording transaction on Bitcoin
blockchain. Where one creditor eager to pay Bitcoin transaction fee in
order to aggregate thousands or even millions different small amount
debt-documents in a single transaction on Bitcoin blockchain.
despite these two cases, the rest of transactions all occur in the Sabu
network (supposed to be over 99%). Thus, no footprint no bottleneck and
no over process.
Another important power point of Sabu is its pure-peer-to-peer network
architecture. In Sabu the mobile wallets communicating to each other
directly without any central server. There is no centralization at all.
As a result, there will be no routing as well.
Since only issuer and creditors are aware of the content of transaction
(who pay how much to whom) it is a huge privacy improvement, which
doesn’t exist in other layer 2 solutions.
About the usability of Sabu, although the protocol based on the
collaborating 2 different peer-to-peer network and 3 classic
server/client networks, but the end user (mobile wallet user) doesn’t
see any of these complexities.
The end user simply installs the mobile/desktop wallet and add her/his
friends to his phonebook by adding their email address or scanning their
email (and/or PGP public key). After that s/he can immediately start to
send/receive Bitcoin through Sabu network. Entire communications between
wallets are PGP encrypted.
Another good point in Sabu design is, the 12 seed words are using for
both Bitcoin wallet private key and the PGP private key. So, it is the
key of user wealth and its identity as well. For more details, please
read my previous answer to Alex Schoof.
The issuer, by using his UTXOs and selling them to creditors earn money.
the issuer creates the debt document (transaction) by which promises to
creditor an amount of satoshi. These debt documents are valid Bitcoin
transaction. The only difference is these transactions are intended to
circulate in Sabu protocol instead of sending to Bitcoin blockchain.
Each transaction is a small money transfer. 40,000 Satoshi as input and
maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
transaction fee.
The creditors will use these received transactions as money and will pay
it in exchange of goods or services. For each transaction the creditor
pays 10 Satoshi as Sabu-transaction-fee to issuer.
Sabu is not custodial service and the UXTOs are always under issuer
control, unless issuer or creditor send the signed transaction to
Bitcoin network. When the transaction was recorded in Bitcoin
blockchain, the creditor can spend proper UTXO in Bitcoin network.
Imagine million people use their UTXOs in Sabu, they are issuer and
issue/update/cancel million transactions per second. All they need is a
mobile wallet. On the other hand, every one by knowing an issuer can buy
some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
it, this time Alice really can buy caffe by Bitcoin ;)
The Bar can install the mobile wallet and every day receives thousands
of debt documents (transactions), each worth maximum 20,000 Satoshi in
exchange of coffee. And every evening aggregates those small
transactions to one single transaction and send it to Bitcoin network.
The security model of Sabu is pretty straight forward.
Issuer is the owner of UTXO(s) which will be used in transactions. The
issuer is and will the only person who creates transactions and sign
them. The transactions are valid transaction which either issuer or
creditor can send them to Bitcoin network, but they will never send
these transactions to Bitcoin network, because of the high Bitcoin
transaction fee for each single transaction.
Since issuer is the only one who can sign transaction (spend UTXOs),
there is a risk of issuer cheating. And no one can stop issuer from
cheating, because these are his UTXOs and he has the proper private
keys.
The Sabu solution is Guarantee transaction. It is a valid transaction
that issuer has to sign it alongside the Main transaction. In GT both
issuer and creditor cut a part of their output in favor of Bitcoin
transaction fee.
We suppose miners always seeking for more profit, thus in a case there
are 2 or more transaction are spending same UTXO as input, miner will
choose transaction with highest feeRate. There is no economically
benefit for issuer to cheat creditors and pay less transaction fee
simultaneously. So rationally the issuer won’t cheat creditor.
It was the simplest explanation of Sabu security model.
> I agree with others that using email is probably not appropriate for a protocol like this. I would highly recommend making your protocol transport-agnostic, allowing users of your protocol to use any transport they want.
Indeed, the protocol is transparent-agnostic, if I insist of email as a
user identifier and communicating tool is because of the idea of
reforming part of internet architecture and make it more decentralized.
The wallet users can choose classic architecture. In this case mobile
wallets will connect to a central server and communicate through that
server (pretty much like all existed mobile wallets). While some users
decide to use a pure peer-to-peer communication. I knew email has some
privacy issues but as always it is a tradeoff. Users can decide between
an unstoppable, permission less, self-sovereignty and decentralized pure
peer-to-peer communication network (with some resolvable privacy issues)
or some efficient central limited network.
Let me know the critics about email. Hopefully this would lead us to
improve email instead of letting it die. I strongly suggest email
because it is the ONLY neutral, free “nonproprietary” and open
protocol/technology for communication in the world that its
infrastructure is well-established and is accessible all over the glob.
I tried to explain it more, hope was useful. By the way the complete
explanation is here
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
Regards
Raymo
On 2021-06-22 18:20, Billy Tetrud wrote:
> I would be interested in seeing some more information about the
> benefits of this approach vs alternatives up front in this write up.
> Eg how does the security, cost, usability, and privacy compare to the
> lightning network, which would be the most likely competitor to this
> idea. It seems clear that there is more counterparty risk here, so it
> would probably also be very helpful to compare against traditional
> custodial solutions as well. If you have specific claims on how this
> system is better than eg lightning in certain contexts, it would be
> far easier to evaluate the protocol against those claims, and would
> also be a lot easier for readers to be motivated to read the whole
> protocol and do a more full analysis.
>
> I agree with others that using email is probably not appropriate for a
> protocol like this. I would highly recommend making your protocol
> transport-agnostic, allowing users of your protocol to use any
> transport they want.
>
> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> I think you're making a number of assumptions about mining that are
>> not accurate.
>>
>>> First of all, how much chance in finding next block the corrupted
>> miners have? One percent of all Bitcoin hash powers? Or maximum 5
>> percent or 10? The cheaters must come up in dividing that 1.2
>> Bitcoin between. After all the risk/reward must fit them. They can
>> not be a big mining pool since there is no benefit, so they will be
>> small miners with low hash rate. If they solve the puzzle and
>> broadcast the block, no one in the entire Bitcoin network has block
>> transactions or seen it before in their mempool!
>>
>> You're making the assumption that miners won't build on top of a
>> block
>> with transactions they have not seen before or transactions that may
>> contain double spends of unconfirmed inputs, this is not how mining
>> works, as long as the block passes the consensus rules effectively
>> all
>> miners will mine on top of it by default, this behavior is
>> fundamental
>> to how mining currently works and is fairly deeply baked into the
>> current mining infrastructure.
>>
>>> Will they accept this block? In theory it is possible and have
>> 0.01 percent chance but we can eliminate this small possibilities by
>> a simple BIP for miners.
>>
>> What would this BIP look like? I don't see how this could work in a
>> decentralized way as you would need another way of reaching
>> consensus
>> on what defines a valid block. Right now the chance is nearly 100
>> percent that a miner will mine on top of the latest valid block,
>> many
>> pools(most last I checked) will even mine on the next block before
>> they validate the latest block fully(ie validationless mining) to
>> reduce their orphan rates.
>>
>>> We suppose the miners always control transactions with
>> doc-watchers and avoid accepting transaction with same UTXO but
>> different output.
>>
>> Miners have different mempool policy/rules for what transactions
>> they
>> themselves mine but all miners must mine on the most work chain of
>> valid blocks otherwise they risk their own blocks being orphaned,
>> any
>> miner that does not do this is effectively guaranteed to have their
>> block orphaned right now.
>>
>>> Because of high Bitcoin transaction fee, this guarantee
>> transaction will take place in next block, even if other transaction
>> which are using the same UTXO as input existed in mempool.
>>
>> When a new transaction is broadcast miners do not immediately start
>> mining on a block template that includes that transaction, the
>> template won't even be generated immediately when it enters a miners
>> mempool in practice, for bandwidth/network efficiency reasons mining
>> pools batch update the stratum templates/jobs they mine against so
>> there can be significant latency between the time a transaction is
>> actually broadcast and hits the miners mempool and the time the
>> miners
>> actually switch to mining on top it, these batched updates are
>> essentially like point in time snapshots of the mempool and
>> typically
>> remain valid(as in the pool will accept shares submitted against
>> that
>> job as valid) until the bitcoin network finds the next block. I
>> don't
>> think these batch updates are done more often than every 30 seconds
>> typically, while often it is on the order of multiple minutes
>> depending on the pool.
>>
>> Regards,
>> James
>>
>> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
>> <bitcoin-dev@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-01 20:11 ` raymo
@ 2021-07-01 20:49 ` Erik Aronesty
2021-07-01 22:15 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Erik Aronesty @ 2021-07-01 20:49 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
your protocol should always assume the email system is fully
compromised, and only send public information over email:
- public keys / addresses are sent
- other routing data encrypted with public keys (not sure how data is
routed in sabu)
your end user should be able to verify public keys / addresses
- use QR-codes
- phone calls with users reading BIP words out loud
- other in-person information exchange
separate the Sabu protocol from the app... allow others to implement
desktop version, or other versions that use other routing systems
- you can allow direct-entry of a BIP-word-representation of a public
key/address to avoid privacy/central system concerns
On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi Billy,
> Sorry for late reply. Let’s jump in proposal.
>
> > Some more information about the benefits of this approach vs alternatives (mainly lightning)
> The most important different is unlike the lightning, in Sabu no one
> have to open a channel and pay Bitcoin transaction fee, subsequently no
> one has to close channel and pay another Bitcoin transaction fee. It is
> the huge improvement since it drops the overhead cost of transactions.
> So, it will be more convenience to trade under Sabu protocol.
> In Sabu none of parties of a transaction are obliged to block money in
> any kind of smart contract or any other m of n signature accounts
> on-chain, so it provides more privacy.
> Since Sabu protocol is designed to motivate people to circulate
> transactions (AKA debt documents) in Sabu network, if every actor act
> rationally no one will aware how much money transferred from who to
> whom.
> In case of fraudulent activity by issuer, the creditor will send
> Guarantee Transaction (GT) to Bitcoin network in order to recapture the
> part of his credit. So, in this case the transaction is literally
> recorded on bitcoin blockchain.
> There is only one another reason to recording transaction on Bitcoin
> blockchain. Where one creditor eager to pay Bitcoin transaction fee in
> order to aggregate thousands or even millions different small amount
> debt-documents in a single transaction on Bitcoin blockchain.
> despite these two cases, the rest of transactions all occur in the Sabu
> network (supposed to be over 99%). Thus, no footprint no bottleneck and
> no over process.
>
> Another important power point of Sabu is its pure-peer-to-peer network
> architecture. In Sabu the mobile wallets communicating to each other
> directly without any central server. There is no centralization at all.
> As a result, there will be no routing as well.
> Since only issuer and creditors are aware of the content of transaction
> (who pay how much to whom) it is a huge privacy improvement, which
> doesn’t exist in other layer 2 solutions.
>
> About the usability of Sabu, although the protocol based on the
> collaborating 2 different peer-to-peer network and 3 classic
> server/client networks, but the end user (mobile wallet user) doesn’t
> see any of these complexities.
> The end user simply installs the mobile/desktop wallet and add her/his
> friends to his phonebook by adding their email address or scanning their
> email (and/or PGP public key). After that s/he can immediately start to
> send/receive Bitcoin through Sabu network. Entire communications between
> wallets are PGP encrypted.
> Another good point in Sabu design is, the 12 seed words are using for
> both Bitcoin wallet private key and the PGP private key. So, it is the
> key of user wealth and its identity as well. For more details, please
> read my previous answer to Alex Schoof.
> The issuer, by using his UTXOs and selling them to creditors earn money.
> the issuer creates the debt document (transaction) by which promises to
> creditor an amount of satoshi. These debt documents are valid Bitcoin
> transaction. The only difference is these transactions are intended to
> circulate in Sabu protocol instead of sending to Bitcoin blockchain.
> Each transaction is a small money transfer. 40,000 Satoshi as input and
> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
> transaction fee.
> The creditors will use these received transactions as money and will pay
> it in exchange of goods or services. For each transaction the creditor
> pays 10 Satoshi as Sabu-transaction-fee to issuer.
> Sabu is not custodial service and the UXTOs are always under issuer
> control, unless issuer or creditor send the signed transaction to
> Bitcoin network. When the transaction was recorded in Bitcoin
> blockchain, the creditor can spend proper UTXO in Bitcoin network.
> Imagine million people use their UTXOs in Sabu, they are issuer and
> issue/update/cancel million transactions per second. All they need is a
> mobile wallet. On the other hand, every one by knowing an issuer can buy
> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
> it, this time Alice really can buy caffe by Bitcoin ;)
> The Bar can install the mobile wallet and every day receives thousands
> of debt documents (transactions), each worth maximum 20,000 Satoshi in
> exchange of coffee. And every evening aggregates those small
> transactions to one single transaction and send it to Bitcoin network.
>
>
> The security model of Sabu is pretty straight forward.
> Issuer is the owner of UTXO(s) which will be used in transactions. The
> issuer is and will the only person who creates transactions and sign
> them. The transactions are valid transaction which either issuer or
> creditor can send them to Bitcoin network, but they will never send
> these transactions to Bitcoin network, because of the high Bitcoin
> transaction fee for each single transaction.
> Since issuer is the only one who can sign transaction (spend UTXOs),
> there is a risk of issuer cheating. And no one can stop issuer from
> cheating, because these are his UTXOs and he has the proper private
> keys.
> The Sabu solution is Guarantee transaction. It is a valid transaction
> that issuer has to sign it alongside the Main transaction. In GT both
> issuer and creditor cut a part of their output in favor of Bitcoin
> transaction fee.
> We suppose miners always seeking for more profit, thus in a case there
> are 2 or more transaction are spending same UTXO as input, miner will
> choose transaction with highest feeRate. There is no economically
> benefit for issuer to cheat creditors and pay less transaction fee
> simultaneously. So rationally the issuer won’t cheat creditor.
> It was the simplest explanation of Sabu security model.
>
> > I agree with others that using email is probably not appropriate for a protocol like this. I would highly recommend making your protocol transport-agnostic, allowing users of your protocol to use any transport they want.
> Indeed, the protocol is transparent-agnostic, if I insist of email as a
> user identifier and communicating tool is because of the idea of
> reforming part of internet architecture and make it more decentralized.
> The wallet users can choose classic architecture. In this case mobile
> wallets will connect to a central server and communicate through that
> server (pretty much like all existed mobile wallets). While some users
> decide to use a pure peer-to-peer communication. I knew email has some
> privacy issues but as always it is a tradeoff. Users can decide between
> an unstoppable, permission less, self-sovereignty and decentralized pure
> peer-to-peer communication network (with some resolvable privacy issues)
> or some efficient central limited network.
> Let me know the critics about email. Hopefully this would lead us to
> improve email instead of letting it die. I strongly suggest email
> because it is the ONLY neutral, free “nonproprietary” and open
> protocol/technology for communication in the world that its
> infrastructure is well-established and is accessible all over the glob.
>
> I tried to explain it more, hope was useful. By the way the complete
> explanation is here
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
>
>
> Regards
> Raymo
>
>
>
> On 2021-06-22 18:20, Billy Tetrud wrote:
> > I would be interested in seeing some more information about the
> > benefits of this approach vs alternatives up front in this write up.
> > Eg how does the security, cost, usability, and privacy compare to the
> > lightning network, which would be the most likely competitor to this
> > idea. It seems clear that there is more counterparty risk here, so it
> > would probably also be very helpful to compare against traditional
> > custodial solutions as well. If you have specific claims on how this
> > system is better than eg lightning in certain contexts, it would be
> > far easier to evaluate the protocol against those claims, and would
> > also be a lot easier for readers to be motivated to read the whole
> > protocol and do a more full analysis.
> >
> > I agree with others that using email is probably not appropriate for a
> > protocol like this. I would highly recommend making your protocol
> > transport-agnostic, allowing users of your protocol to use any
> > transport they want.
> >
> > On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> I think you're making a number of assumptions about mining that are
> >> not accurate.
> >>
> >>> First of all, how much chance in finding next block the corrupted
> >> miners have? One percent of all Bitcoin hash powers? Or maximum 5
> >> percent or 10? The cheaters must come up in dividing that 1.2
> >> Bitcoin between. After all the risk/reward must fit them. They can
> >> not be a big mining pool since there is no benefit, so they will be
> >> small miners with low hash rate. If they solve the puzzle and
> >> broadcast the block, no one in the entire Bitcoin network has block
> >> transactions or seen it before in their mempool!
> >>
> >> You're making the assumption that miners won't build on top of a
> >> block
> >> with transactions they have not seen before or transactions that may
> >> contain double spends of unconfirmed inputs, this is not how mining
> >> works, as long as the block passes the consensus rules effectively
> >> all
> >> miners will mine on top of it by default, this behavior is
> >> fundamental
> >> to how mining currently works and is fairly deeply baked into the
> >> current mining infrastructure.
> >>
> >>> Will they accept this block? In theory it is possible and have
> >> 0.01 percent chance but we can eliminate this small possibilities by
> >> a simple BIP for miners.
> >>
> >> What would this BIP look like? I don't see how this could work in a
> >> decentralized way as you would need another way of reaching
> >> consensus
> >> on what defines a valid block. Right now the chance is nearly 100
> >> percent that a miner will mine on top of the latest valid block,
> >> many
> >> pools(most last I checked) will even mine on the next block before
> >> they validate the latest block fully(ie validationless mining) to
> >> reduce their orphan rates.
> >>
> >>> We suppose the miners always control transactions with
> >> doc-watchers and avoid accepting transaction with same UTXO but
> >> different output.
> >>
> >> Miners have different mempool policy/rules for what transactions
> >> they
> >> themselves mine but all miners must mine on the most work chain of
> >> valid blocks otherwise they risk their own blocks being orphaned,
> >> any
> >> miner that does not do this is effectively guaranteed to have their
> >> block orphaned right now.
> >>
> >>> Because of high Bitcoin transaction fee, this guarantee
> >> transaction will take place in next block, even if other transaction
> >> which are using the same UTXO as input existed in mempool.
> >>
> >> When a new transaction is broadcast miners do not immediately start
> >> mining on a block template that includes that transaction, the
> >> template won't even be generated immediately when it enters a miners
> >> mempool in practice, for bandwidth/network efficiency reasons mining
> >> pools batch update the stratum templates/jobs they mine against so
> >> there can be significant latency between the time a transaction is
> >> actually broadcast and hits the miners mempool and the time the
> >> miners
> >> actually switch to mining on top it, these batched updates are
> >> essentially like point in time snapshots of the mempool and
> >> typically
> >> remain valid(as in the pool will accept shares submitted against
> >> that
> >> job as valid) until the bitcoin network finds the next block. I
> >> don't
> >> think these batch updates are done more often than every 30 seconds
> >> typically, while often it is on the order of multiple minutes
> >> depending on the pool.
> >>
> >> Regards,
> >> James
> >>
> >> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> >> <bitcoin-dev@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@lists•linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-01 20:49 ` Erik Aronesty
@ 2021-07-01 22:15 ` raymo
2021-07-02 17:57 ` Billy Tetrud
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-07-01 22:15 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, Billy Tetrud
Hi Erik
Please correct me if I misunderstood.
> email is fully compromised.
What I got is:
Email is not good because the sender and receiver are compromised.
Email is not good because the message content is revealed.
I can claim same argue about any other client/server model. Since the
server (website) service provider will ask some sort of KYC. And even if
the server uses end-to-end encryption, the provider company still can
read the packets content.
In my model the passive listener only can discover who is communicate to
whom and make a graph of connections. Although it is a threat for
privacy but the server/client model has this flaw inherently, since
provider already knew everything about everyone. In my model at least
users can make some fake connections and send some fake emails in order
to inject noise to communications.
Please note the fact that entire communication between mobile wallets
(via emails) are asymmetric PGP encrypted. The PGP keys are controlled
by end users unlike ALL pretending secure messengers (e.g whatsApp,
signal, zoom,…).
If you are worried about the way of exchanging PGP public key, you are
right. The most secure way is in-person PGP key exchanging.
After that for payments the wallets communicate in pgp encrypted
messages and they can transfer Bitcoin address through an PGP encrypted
cipher, thus no revealing Bitcoin address to public would occur. Neither
the amounts of transactions will be reviled.
There for it would be a good practice for shops to put their email and
PGP public key on shop website and/or PGP public key servers, instead of
putting Bitcoin address on website or using 3rd parties services to hide
their Bitcoin payment addresses.
If I missed some points about “fully compromised” please write it to me.
> public keys / addresses are sent
As I told before ALL communication in Sabu are PGP encrypted.
> other routing data encrypted with public keys
>(not sure how data is routed in sabu)
Sabu is not responsible for routing at all. It simply sends emails.
Indeed the wallets peer-to-peer network in Sabu is pretty straight
forward. Each mobile wallet has one email address as its handler and
identifier in mobile-wallets-network. Each mobile can send message to
another mobile by knowing its email address and the PGP public key.
This information can be prepared in first face-to-face contact of mobile
owners, or later (something like signing the other’s public key in web
of trust) when a creditor wants to spend his money and transfer it to
another creditor. The creditor1 send the signed money transfer request
alongside the email and public key of creditor2 all in a PGP encrypted
message to issuer.
> separate the Sabu protocol from the app... allow others to implement
> desktop version, or other versions that use other routing systems
Indeed, it is my approach too. As I told before users will decide
between an unstoppable, permission less, self-sovereignty and
decentralized pure peer-to-peer communication network (with some
resolvable privacy issues) or some efficient, privacy-mimic central
limited network.
> you can allow direct-entry of a BIP-word-representation
> of a public key/address to avoid privacy/central system concerns
Agree. Actually, I was thinking about an easy mechanism to share your
public key like what you suggested here.
But what I consider for a “central system concerns” is the ability of
communication without dependency to any company.
As an example, what can you do if the twitter bans your account?
Nothing! Your content and entire connections will be lost.
But if you form your friends list in your mobile (or computer) and have
their PGP public keys and they have yours, and use email as a dual
purpose tool. First as a handler (the tool for finding and to be found
in internet) and second as a communication tool.
Thus, no one can stop you, ban you or limit you to send/receive
transaction to/from anyone.
What I am trying to say is using email is far better than account
(username) in a limited central service like twitter, Facebook,
telegram... or even in future Sabu servers!
You have your connections under your control in your phone. You can
easily change your email and use a new email or even a new service
provider without losing your connections and your control over it.
You just sign your new email address and send it to your friends circle
and notify them about changes.
Of course, email is not good for millions of followers but it is
obviously good for managing your payment network of hundreds of people
(either issuers or creditors).
Best
Raymo
On 2021-07-01 20:49, Erik Aronesty wrote:
> your protocol should always assume the email system is fully
> compromised, and only send public information over email:
>
> - public keys / addresses are sent
> - other routing data encrypted with public keys (not sure how data is
> routed in sabu)
>
> your end user should be able to verify public keys / addresses
>
> - use QR-codes
> - phone calls with users reading BIP words out loud
> - other in-person information exchange
>
> separate the Sabu protocol from the app... allow others to implement
> desktop version, or other versions that use other routing systems
>
> - you can allow direct-entry of a BIP-word-representation of a public
> key/address to avoid privacy/central system concerns
>
> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Hi Billy,
>> Sorry for late reply. Let’s jump in proposal.
>>
>> > Some more information about the benefits of this approach vs alternatives (mainly lightning)
>> The most important different is unlike the lightning, in Sabu no one
>> have to open a channel and pay Bitcoin transaction fee, subsequently no
>> one has to close channel and pay another Bitcoin transaction fee. It is
>> the huge improvement since it drops the overhead cost of transactions.
>> So, it will be more convenience to trade under Sabu protocol.
>> In Sabu none of parties of a transaction are obliged to block money in
>> any kind of smart contract or any other m of n signature accounts
>> on-chain, so it provides more privacy.
>> Since Sabu protocol is designed to motivate people to circulate
>> transactions (AKA debt documents) in Sabu network, if every actor act
>> rationally no one will aware how much money transferred from who to
>> whom.
>> In case of fraudulent activity by issuer, the creditor will send
>> Guarantee Transaction (GT) to Bitcoin network in order to recapture the
>> part of his credit. So, in this case the transaction is literally
>> recorded on bitcoin blockchain.
>> There is only one another reason to recording transaction on Bitcoin
>> blockchain. Where one creditor eager to pay Bitcoin transaction fee in
>> order to aggregate thousands or even millions different small amount
>> debt-documents in a single transaction on Bitcoin blockchain.
>> despite these two cases, the rest of transactions all occur in the Sabu
>> network (supposed to be over 99%). Thus, no footprint no bottleneck and
>> no over process.
>>
>> Another important power point of Sabu is its pure-peer-to-peer network
>> architecture. In Sabu the mobile wallets communicating to each other
>> directly without any central server. There is no centralization at all.
>> As a result, there will be no routing as well.
>> Since only issuer and creditors are aware of the content of transaction
>> (who pay how much to whom) it is a huge privacy improvement, which
>> doesn’t exist in other layer 2 solutions.
>>
>> About the usability of Sabu, although the protocol based on the
>> collaborating 2 different peer-to-peer network and 3 classic
>> server/client networks, but the end user (mobile wallet user) doesn’t
>> see any of these complexities.
>> The end user simply installs the mobile/desktop wallet and add her/his
>> friends to his phonebook by adding their email address or scanning their
>> email (and/or PGP public key). After that s/he can immediately start to
>> send/receive Bitcoin through Sabu network. Entire communications between
>> wallets are PGP encrypted.
>> Another good point in Sabu design is, the 12 seed words are using for
>> both Bitcoin wallet private key and the PGP private key. So, it is the
>> key of user wealth and its identity as well. For more details, please
>> read my previous answer to Alex Schoof.
>> The issuer, by using his UTXOs and selling them to creditors earn money.
>> the issuer creates the debt document (transaction) by which promises to
>> creditor an amount of satoshi. These debt documents are valid Bitcoin
>> transaction. The only difference is these transactions are intended to
>> circulate in Sabu protocol instead of sending to Bitcoin blockchain.
>> Each transaction is a small money transfer. 40,000 Satoshi as input and
>> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
>> transaction fee.
>> The creditors will use these received transactions as money and will pay
>> it in exchange of goods or services. For each transaction the creditor
>> pays 10 Satoshi as Sabu-transaction-fee to issuer.
>> Sabu is not custodial service and the UXTOs are always under issuer
>> control, unless issuer or creditor send the signed transaction to
>> Bitcoin network. When the transaction was recorded in Bitcoin
>> blockchain, the creditor can spend proper UTXO in Bitcoin network.
>> Imagine million people use their UTXOs in Sabu, they are issuer and
>> issue/update/cancel million transactions per second. All they need is a
>> mobile wallet. On the other hand, every one by knowing an issuer can buy
>> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
>> it, this time Alice really can buy caffe by Bitcoin ;)
>> The Bar can install the mobile wallet and every day receives thousands
>> of debt documents (transactions), each worth maximum 20,000 Satoshi in
>> exchange of coffee. And every evening aggregates those small
>> transactions to one single transaction and send it to Bitcoin network.
>>
>>
>> The security model of Sabu is pretty straight forward.
>> Issuer is the owner of UTXO(s) which will be used in transactions. The
>> issuer is and will the only person who creates transactions and sign
>> them. The transactions are valid transaction which either issuer or
>> creditor can send them to Bitcoin network, but they will never send
>> these transactions to Bitcoin network, because of the high Bitcoin
>> transaction fee for each single transaction.
>> Since issuer is the only one who can sign transaction (spend UTXOs),
>> there is a risk of issuer cheating. And no one can stop issuer from
>> cheating, because these are his UTXOs and he has the proper private
>> keys.
>> The Sabu solution is Guarantee transaction. It is a valid transaction
>> that issuer has to sign it alongside the Main transaction. In GT both
>> issuer and creditor cut a part of their output in favor of Bitcoin
>> transaction fee.
>> We suppose miners always seeking for more profit, thus in a case there
>> are 2 or more transaction are spending same UTXO as input, miner will
>> choose transaction with highest feeRate. There is no economically
>> benefit for issuer to cheat creditors and pay less transaction fee
>> simultaneously. So rationally the issuer won’t cheat creditor.
>> It was the simplest explanation of Sabu security model.
>>
>> > I agree with others that using email is probably not appropriate for a protocol like this. I would highly recommend making your protocol transport-agnostic, allowing users of your protocol to use any transport they want.
>> Indeed, the protocol is transparent-agnostic, if I insist of email as a
>> user identifier and communicating tool is because of the idea of
>> reforming part of internet architecture and make it more decentralized.
>> The wallet users can choose classic architecture. In this case mobile
>> wallets will connect to a central server and communicate through that
>> server (pretty much like all existed mobile wallets). While some users
>> decide to use a pure peer-to-peer communication. I knew email has some
>> privacy issues but as always it is a tradeoff. Users can decide between
>> an unstoppable, permission less, self-sovereignty and decentralized pure
>> peer-to-peer communication network (with some resolvable privacy issues)
>> or some efficient central limited network.
>> Let me know the critics about email. Hopefully this would lead us to
>> improve email instead of letting it die. I strongly suggest email
>> because it is the ONLY neutral, free “nonproprietary” and open
>> protocol/technology for communication in the world that its
>> infrastructure is well-established and is accessible all over the glob.
>>
>> I tried to explain it more, hope was useful. By the way the complete
>> explanation is here
>> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>
>>
>>
>> Regards
>> Raymo
>>
>>
>>
>> On 2021-06-22 18:20, Billy Tetrud wrote:
>> > I would be interested in seeing some more information about the
>> > benefits of this approach vs alternatives up front in this write up.
>> > Eg how does the security, cost, usability, and privacy compare to the
>> > lightning network, which would be the most likely competitor to this
>> > idea. It seems clear that there is more counterparty risk here, so it
>> > would probably also be very helpful to compare against traditional
>> > custodial solutions as well. If you have specific claims on how this
>> > system is better than eg lightning in certain contexts, it would be
>> > far easier to evaluate the protocol against those claims, and would
>> > also be a lot easier for readers to be motivated to read the whole
>> > protocol and do a more full analysis.
>> >
>> > I agree with others that using email is probably not appropriate for a
>> > protocol like this. I would highly recommend making your protocol
>> > transport-agnostic, allowing users of your protocol to use any
>> > transport they want.
>> >
>> > On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
>> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> >> I think you're making a number of assumptions about mining that are
>> >> not accurate.
>> >>
>> >>> First of all, how much chance in finding next block the corrupted
>> >> miners have? One percent of all Bitcoin hash powers? Or maximum 5
>> >> percent or 10? The cheaters must come up in dividing that 1.2
>> >> Bitcoin between. After all the risk/reward must fit them. They can
>> >> not be a big mining pool since there is no benefit, so they will be
>> >> small miners with low hash rate. If they solve the puzzle and
>> >> broadcast the block, no one in the entire Bitcoin network has block
>> >> transactions or seen it before in their mempool!
>> >>
>> >> You're making the assumption that miners won't build on top of a
>> >> block
>> >> with transactions they have not seen before or transactions that may
>> >> contain double spends of unconfirmed inputs, this is not how mining
>> >> works, as long as the block passes the consensus rules effectively
>> >> all
>> >> miners will mine on top of it by default, this behavior is
>> >> fundamental
>> >> to how mining currently works and is fairly deeply baked into the
>> >> current mining infrastructure.
>> >>
>> >>> Will they accept this block? In theory it is possible and have
>> >> 0.01 percent chance but we can eliminate this small possibilities by
>> >> a simple BIP for miners.
>> >>
>> >> What would this BIP look like? I don't see how this could work in a
>> >> decentralized way as you would need another way of reaching
>> >> consensus
>> >> on what defines a valid block. Right now the chance is nearly 100
>> >> percent that a miner will mine on top of the latest valid block,
>> >> many
>> >> pools(most last I checked) will even mine on the next block before
>> >> they validate the latest block fully(ie validationless mining) to
>> >> reduce their orphan rates.
>> >>
>> >>> We suppose the miners always control transactions with
>> >> doc-watchers and avoid accepting transaction with same UTXO but
>> >> different output.
>> >>
>> >> Miners have different mempool policy/rules for what transactions
>> >> they
>> >> themselves mine but all miners must mine on the most work chain of
>> >> valid blocks otherwise they risk their own blocks being orphaned,
>> >> any
>> >> miner that does not do this is effectively guaranteed to have their
>> >> block orphaned right now.
>> >>
>> >>> Because of high Bitcoin transaction fee, this guarantee
>> >> transaction will take place in next block, even if other transaction
>> >> which are using the same UTXO as input existed in mempool.
>> >>
>> >> When a new transaction is broadcast miners do not immediately start
>> >> mining on a block template that includes that transaction, the
>> >> template won't even be generated immediately when it enters a miners
>> >> mempool in practice, for bandwidth/network efficiency reasons mining
>> >> pools batch update the stratum templates/jobs they mine against so
>> >> there can be significant latency between the time a transaction is
>> >> actually broadcast and hits the miners mempool and the time the
>> >> miners
>> >> actually switch to mining on top it, these batched updates are
>> >> essentially like point in time snapshots of the mempool and
>> >> typically
>> >> remain valid(as in the pool will accept shares submitted against
>> >> that
>> >> job as valid) until the bitcoin network finds the next block. I
>> >> don't
>> >> think these batch updates are done more often than every 30 seconds
>> >> typically, while often it is on the order of multiple minutes
>> >> depending on the pool.
>> >>
>> >> Regards,
>> >> James
>> >>
>> >> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
>> >> <bitcoin-dev@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@lists•linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists•linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-01 22:15 ` raymo
@ 2021-07-02 17:57 ` Billy Tetrud
2021-07-03 8:02 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Billy Tetrud @ 2021-07-02 17:57 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 22010 bytes --]
Thanks for the details Raymo. A thought occurred to me. Given the fact that
miners can abuse this system without penalty, it would be useful to be able
to fix this. What if it was possible for the creditor to claw back the
funds even if the cheating transaction was mined instead of the guarantee
transaction? Let's say there was a way to sign a transaction that gives the
receiver of that transaction the ability to override any other transaction
that uses the UTXO? If this were possible, the issuer could give the
creditor this kind of transaction as the guarantee transaction, and in the
case a cheat was done, the creditor could still use the GT to reallocate
that UTXO to themselves.
Now there are issues with this. First of all, it could give anyone the
ability to double spend. So it would be prudent to limit this in some way.
The revocation probably should only be valid for up to 6 blocks, such that
if the transaction has 6 confirmations, it can no longer be reallocated
(thus preserving the 6 block finality rule). It could also be required that
the UTXO be marked as opting into this behavior (so receivers would know
about the possibility it could get revoked). This second requirement would
require Sabu issuers to make an on-chain transaction to set themselves
up as an issuer.
Another issue is that this would make it possible for transactions to
expire. Any claw-back transaction would expire 6 blocks after the initial
transaction happened. This has been generally avoided in bitcoin, but I
think the relevant issues are solvable. You can find additional discussion
of that in this thread
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html>
.
I would imagine this kind of ability would be pretty controversial, but
since it can close out the possibility for miners to escape punishment, it
could make this protocol viable.
On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup•net> wrote:
>
> Hi Erik
>
> Please correct me if I misunderstood.
>
> > email is fully compromised.
>
> What I got is:
> Email is not good because the sender and receiver are compromised.
> Email is not good because the message content is revealed.
> I can claim same argue about any other client/server model. Since the
> server (website) service provider will ask some sort of KYC. And even if
> the server uses end-to-end encryption, the provider company still can
> read the packets content.
> In my model the passive listener only can discover who is communicate to
> whom and make a graph of connections. Although it is a threat for
> privacy but the server/client model has this flaw inherently, since
> provider already knew everything about everyone. In my model at least
> users can make some fake connections and send some fake emails in order
> to inject noise to communications.
> Please note the fact that entire communication between mobile wallets
> (via emails) are asymmetric PGP encrypted. The PGP keys are controlled
> by end users unlike ALL pretending secure messengers (e.g whatsApp,
> signal, zoom,…).
> If you are worried about the way of exchanging PGP public key, you are
> right. The most secure way is in-person PGP key exchanging.
> After that for payments the wallets communicate in pgp encrypted
> messages and they can transfer Bitcoin address through an PGP encrypted
> cipher, thus no revealing Bitcoin address to public would occur. Neither
> the amounts of transactions will be reviled.
> There for it would be a good practice for shops to put their email and
> PGP public key on shop website and/or PGP public key servers, instead of
> putting Bitcoin address on website or using 3rd parties services to hide
> their Bitcoin payment addresses.
>
> If I missed some points about “fully compromised” please write it to me.
>
>
> > public keys / addresses are sent
> As I told before ALL communication in Sabu are PGP encrypted.
>
> > other routing data encrypted with public keys
> >(not sure how data is routed in sabu)
>
> Sabu is not responsible for routing at all. It simply sends emails.
> Indeed the wallets peer-to-peer network in Sabu is pretty straight
> forward. Each mobile wallet has one email address as its handler and
> identifier in mobile-wallets-network. Each mobile can send message to
> another mobile by knowing its email address and the PGP public key.
> This information can be prepared in first face-to-face contact of mobile
> owners, or later (something like signing the other’s public key in web
> of trust) when a creditor wants to spend his money and transfer it to
> another creditor. The creditor1 send the signed money transfer request
> alongside the email and public key of creditor2 all in a PGP encrypted
> message to issuer.
>
>
>
> > separate the Sabu protocol from the app... allow others to implement
> > desktop version, or other versions that use other routing systems
>
> Indeed, it is my approach too. As I told before users will decide
> between an unstoppable, permission less, self-sovereignty and
> decentralized pure peer-to-peer communication network (with some
> resolvable privacy issues) or some efficient, privacy-mimic central
> limited network.
>
>
> > you can allow direct-entry of a BIP-word-representation
> > of a public key/address to avoid privacy/central system concerns
> Agree. Actually, I was thinking about an easy mechanism to share your
> public key like what you suggested here.
> But what I consider for a “central system concerns” is the ability of
> communication without dependency to any company.
> As an example, what can you do if the twitter bans your account?
> Nothing! Your content and entire connections will be lost.
> But if you form your friends list in your mobile (or computer) and have
> their PGP public keys and they have yours, and use email as a dual
> purpose tool. First as a handler (the tool for finding and to be found
> in internet) and second as a communication tool.
> Thus, no one can stop you, ban you or limit you to send/receive
> transaction to/from anyone.
> What I am trying to say is using email is far better than account
> (username) in a limited central service like twitter, Facebook,
> telegram... or even in future Sabu servers!
> You have your connections under your control in your phone. You can
> easily change your email and use a new email or even a new service
> provider without losing your connections and your control over it.
> You just sign your new email address and send it to your friends circle
> and notify them about changes.
> Of course, email is not good for millions of followers but it is
> obviously good for managing your payment network of hundreds of people
> (either issuers or creditors).
>
> Best
> Raymo
>
> On 2021-07-01 20:49, Erik Aronesty wrote:
> > your protocol should always assume the email system is fully
> > compromised, and only send public information over email:
> >
> > - public keys / addresses are sent
> > - other routing data encrypted with public keys (not sure how data is
> > routed in sabu)
> >
> > your end user should be able to verify public keys / addresses
> >
> > - use QR-codes
> > - phone calls with users reading BIP words out loud
> > - other in-person information exchange
> >
> > separate the Sabu protocol from the app... allow others to implement
> > desktop version, or other versions that use other routing systems
> >
> > - you can allow direct-entry of a BIP-word-representation of a public
> > key/address to avoid privacy/central system concerns
> >
> > On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>
> >> Hi Billy,
> >> Sorry for late reply. Let’s jump in proposal.
> >>
> >> > Some more information about the benefits of this approach vs
> alternatives (mainly lightning)
> >> The most important different is unlike the lightning, in Sabu no one
> >> have to open a channel and pay Bitcoin transaction fee, subsequently no
> >> one has to close channel and pay another Bitcoin transaction fee. It is
> >> the huge improvement since it drops the overhead cost of transactions.
> >> So, it will be more convenience to trade under Sabu protocol.
> >> In Sabu none of parties of a transaction are obliged to block money in
> >> any kind of smart contract or any other m of n signature accounts
> >> on-chain, so it provides more privacy.
> >> Since Sabu protocol is designed to motivate people to circulate
> >> transactions (AKA debt documents) in Sabu network, if every actor act
> >> rationally no one will aware how much money transferred from who to
> >> whom.
> >> In case of fraudulent activity by issuer, the creditor will send
> >> Guarantee Transaction (GT) to Bitcoin network in order to recapture the
> >> part of his credit. So, in this case the transaction is literally
> >> recorded on bitcoin blockchain.
> >> There is only one another reason to recording transaction on Bitcoin
> >> blockchain. Where one creditor eager to pay Bitcoin transaction fee in
> >> order to aggregate thousands or even millions different small amount
> >> debt-documents in a single transaction on Bitcoin blockchain.
> >> despite these two cases, the rest of transactions all occur in the Sabu
> >> network (supposed to be over 99%). Thus, no footprint no bottleneck and
> >> no over process.
> >>
> >> Another important power point of Sabu is its pure-peer-to-peer network
> >> architecture. In Sabu the mobile wallets communicating to each other
> >> directly without any central server. There is no centralization at all.
> >> As a result, there will be no routing as well.
> >> Since only issuer and creditors are aware of the content of transaction
> >> (who pay how much to whom) it is a huge privacy improvement, which
> >> doesn’t exist in other layer 2 solutions.
> >>
> >> About the usability of Sabu, although the protocol based on the
> >> collaborating 2 different peer-to-peer network and 3 classic
> >> server/client networks, but the end user (mobile wallet user) doesn’t
> >> see any of these complexities.
> >> The end user simply installs the mobile/desktop wallet and add her/his
> >> friends to his phonebook by adding their email address or scanning their
> >> email (and/or PGP public key). After that s/he can immediately start to
> >> send/receive Bitcoin through Sabu network. Entire communications between
> >> wallets are PGP encrypted.
> >> Another good point in Sabu design is, the 12 seed words are using for
> >> both Bitcoin wallet private key and the PGP private key. So, it is the
> >> key of user wealth and its identity as well. For more details, please
> >> read my previous answer to Alex Schoof.
> >> The issuer, by using his UTXOs and selling them to creditors earn money.
> >> the issuer creates the debt document (transaction) by which promises to
> >> creditor an amount of satoshi. These debt documents are valid Bitcoin
> >> transaction. The only difference is these transactions are intended to
> >> circulate in Sabu protocol instead of sending to Bitcoin blockchain.
> >> Each transaction is a small money transfer. 40,000 Satoshi as input and
> >> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
> >> transaction fee.
> >> The creditors will use these received transactions as money and will pay
> >> it in exchange of goods or services. For each transaction the creditor
> >> pays 10 Satoshi as Sabu-transaction-fee to issuer.
> >> Sabu is not custodial service and the UXTOs are always under issuer
> >> control, unless issuer or creditor send the signed transaction to
> >> Bitcoin network. When the transaction was recorded in Bitcoin
> >> blockchain, the creditor can spend proper UTXO in Bitcoin network.
> >> Imagine million people use their UTXOs in Sabu, they are issuer and
> >> issue/update/cancel million transactions per second. All they need is a
> >> mobile wallet. On the other hand, every one by knowing an issuer can buy
> >> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
> >> it, this time Alice really can buy caffe by Bitcoin ;)
> >> The Bar can install the mobile wallet and every day receives thousands
> >> of debt documents (transactions), each worth maximum 20,000 Satoshi in
> >> exchange of coffee. And every evening aggregates those small
> >> transactions to one single transaction and send it to Bitcoin network.
> >>
> >>
> >> The security model of Sabu is pretty straight forward.
> >> Issuer is the owner of UTXO(s) which will be used in transactions. The
> >> issuer is and will the only person who creates transactions and sign
> >> them. The transactions are valid transaction which either issuer or
> >> creditor can send them to Bitcoin network, but they will never send
> >> these transactions to Bitcoin network, because of the high Bitcoin
> >> transaction fee for each single transaction.
> >> Since issuer is the only one who can sign transaction (spend UTXOs),
> >> there is a risk of issuer cheating. And no one can stop issuer from
> >> cheating, because these are his UTXOs and he has the proper private
> >> keys.
> >> The Sabu solution is Guarantee transaction. It is a valid transaction
> >> that issuer has to sign it alongside the Main transaction. In GT both
> >> issuer and creditor cut a part of their output in favor of Bitcoin
> >> transaction fee.
> >> We suppose miners always seeking for more profit, thus in a case there
> >> are 2 or more transaction are spending same UTXO as input, miner will
> >> choose transaction with highest feeRate. There is no economically
> >> benefit for issuer to cheat creditors and pay less transaction fee
> >> simultaneously. So rationally the issuer won’t cheat creditor.
> >> It was the simplest explanation of Sabu security model.
> >>
> >> > I agree with others that using email is probably not appropriate for
> a protocol like this. I would highly recommend making your protocol
> transport-agnostic, allowing users of your protocol to use any transport
> they want.
> >> Indeed, the protocol is transparent-agnostic, if I insist of email as a
> >> user identifier and communicating tool is because of the idea of
> >> reforming part of internet architecture and make it more decentralized.
> >> The wallet users can choose classic architecture. In this case mobile
> >> wallets will connect to a central server and communicate through that
> >> server (pretty much like all existed mobile wallets). While some users
> >> decide to use a pure peer-to-peer communication. I knew email has some
> >> privacy issues but as always it is a tradeoff. Users can decide between
> >> an unstoppable, permission less, self-sovereignty and decentralized pure
> >> peer-to-peer communication network (with some resolvable privacy issues)
> >> or some efficient central limited network.
> >> Let me know the critics about email. Hopefully this would lead us to
> >> improve email instead of letting it die. I strongly suggest email
> >> because it is the ONLY neutral, free “nonproprietary” and open
> >> protocol/technology for communication in the world that its
> >> infrastructure is well-established and is accessible all over the glob.
> >>
> >> I tried to explain it more, hope was useful. By the way the complete
> >> explanation is here
> >>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> >>
> >>
> >>
> >> Regards
> >> Raymo
> >>
> >>
> >>
> >> On 2021-06-22 18:20, Billy Tetrud wrote:
> >> > I would be interested in seeing some more information about the
> >> > benefits of this approach vs alternatives up front in this write up.
> >> > Eg how does the security, cost, usability, and privacy compare to the
> >> > lightning network, which would be the most likely competitor to this
> >> > idea. It seems clear that there is more counterparty risk here, so it
> >> > would probably also be very helpful to compare against traditional
> >> > custodial solutions as well. If you have specific claims on how this
> >> > system is better than eg lightning in certain contexts, it would be
> >> > far easier to evaluate the protocol against those claims, and would
> >> > also be a lot easier for readers to be motivated to read the whole
> >> > protocol and do a more full analysis.
> >> >
> >> > I agree with others that using email is probably not appropriate for a
> >> > protocol like this. I would highly recommend making your protocol
> >> > transport-agnostic, allowing users of your protocol to use any
> >> > transport they want.
> >> >
> >> > On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
> >> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >
> >> >> I think you're making a number of assumptions about mining that are
> >> >> not accurate.
> >> >>
> >> >>> First of all, how much chance in finding next block the corrupted
> >> >> miners have? One percent of all Bitcoin hash powers? Or maximum 5
> >> >> percent or 10? The cheaters must come up in dividing that 1.2
> >> >> Bitcoin between. After all the risk/reward must fit them. They can
> >> >> not be a big mining pool since there is no benefit, so they will be
> >> >> small miners with low hash rate. If they solve the puzzle and
> >> >> broadcast the block, no one in the entire Bitcoin network has block
> >> >> transactions or seen it before in their mempool!
> >> >>
> >> >> You're making the assumption that miners won't build on top of a
> >> >> block
> >> >> with transactions they have not seen before or transactions that may
> >> >> contain double spends of unconfirmed inputs, this is not how mining
> >> >> works, as long as the block passes the consensus rules effectively
> >> >> all
> >> >> miners will mine on top of it by default, this behavior is
> >> >> fundamental
> >> >> to how mining currently works and is fairly deeply baked into the
> >> >> current mining infrastructure.
> >> >>
> >> >>> Will they accept this block? In theory it is possible and have
> >> >> 0.01 percent chance but we can eliminate this small possibilities by
> >> >> a simple BIP for miners.
> >> >>
> >> >> What would this BIP look like? I don't see how this could work in a
> >> >> decentralized way as you would need another way of reaching
> >> >> consensus
> >> >> on what defines a valid block. Right now the chance is nearly 100
> >> >> percent that a miner will mine on top of the latest valid block,
> >> >> many
> >> >> pools(most last I checked) will even mine on the next block before
> >> >> they validate the latest block fully(ie validationless mining) to
> >> >> reduce their orphan rates.
> >> >>
> >> >>> We suppose the miners always control transactions with
> >> >> doc-watchers and avoid accepting transaction with same UTXO but
> >> >> different output.
> >> >>
> >> >> Miners have different mempool policy/rules for what transactions
> >> >> they
> >> >> themselves mine but all miners must mine on the most work chain of
> >> >> valid blocks otherwise they risk their own blocks being orphaned,
> >> >> any
> >> >> miner that does not do this is effectively guaranteed to have their
> >> >> block orphaned right now.
> >> >>
> >> >>> Because of high Bitcoin transaction fee, this guarantee
> >> >> transaction will take place in next block, even if other transaction
> >> >> which are using the same UTXO as input existed in mempool.
> >> >>
> >> >> When a new transaction is broadcast miners do not immediately start
> >> >> mining on a block template that includes that transaction, the
> >> >> template won't even be generated immediately when it enters a miners
> >> >> mempool in practice, for bandwidth/network efficiency reasons mining
> >> >> pools batch update the stratum templates/jobs they mine against so
> >> >> there can be significant latency between the time a transaction is
> >> >> actually broadcast and hits the miners mempool and the time the
> >> >> miners
> >> >> actually switch to mining on top it, these batched updates are
> >> >> essentially like point in time snapshots of the mempool and
> >> >> typically
> >> >> remain valid(as in the pool will accept shares submitted against
> >> >> that
> >> >> job as valid) until the bitcoin network finds the next block. I
> >> >> don't
> >> >> think these batch updates are done more often than every 30 seconds
> >> >> typically, while often it is on the order of multiple minutes
> >> >> depending on the pool.
> >> >>
> >> >> Regards,
> >> >> James
> >> >>
> >> >> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> >> >> <bitcoin-dev@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@lists•linuxfoundation.org
> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> _______________________________________________
> >> >> bitcoin-dev mailing list
> >> >> bitcoin-dev@lists•linuxfoundation.org
> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 26634 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-02 17:57 ` Billy Tetrud
@ 2021-07-03 8:02 ` raymo
2021-07-07 3:20 ` Billy Tetrud
0 siblings, 1 reply; 41+ messages in thread
From: raymo @ 2021-07-03 8:02 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
Hi Billy,
> What if it was possible for the creditor to claw back the funds
As far as I know the “claw back” mechanism doesn’t exist in Bitcoin
system, and probably most Bitcoiners won’t be agree on it.
Even if we want to add claw back to Bitcoin in general, and Sabu in
particular, it would add too complexities and uncertainty to Bitcoin.
So, it would be better to not touch that part, instead focusing on
reduce the cheating risk by putting some penalty for both issuers,
creditors and miners.
We already have the penalties for both issuers and creditors.
It looks the miners still can abuse Sabu, but as I told before the miner
or better say the mining pool must be issuer (to be able to sign the
promised UTXO in cheating way) or must be creditor (in order to have a
copy of GT and not lose his money in favor of a stranger miner. Remember
the fact that creditor will lose 70% of their money in favor of Bitcoin
transaction fee in a typical GT) or collaborate one of them in a
conspiracy. Otherwise, there will be no economic benefit in this attack.
All these 3 cases of the attacks, theoretically could be happened, but
the risk to reward ratio is enough high to hinder potential malevolent
from a practical act.
Even this very small risk of miner attacks (which don’t care the attack
costs, since he is not interested in economic benefit, but he wants to
ruin Sabu), would be resolved by a slightly upgrade in Bitcoin protocol
by applying the BIPxxx “for flagging/unflagging promised UTXOs”.
I am not in rush to apply this upgrade on Bitcoin protocol, instead I am
actively working in order to realize the Sabu protocol and Gazin wallet.
Later the Sabu community will carry the BIPxxx.
Best
On 2021-07-02 17:57, Billy Tetrud wrote:
> Thanks for the details Raymo. A thought occurred to me. Given the fact
> that miners can abuse this system without penalty, it would be useful
> to be able to fix this. What if it was possible for the creditor to
> claw back the funds even if the cheating transaction was mined instead
> of the guarantee transaction? Let's say there was a way to sign a
> transaction that gives the receiver of that transaction the ability to
> override any other transaction that uses the UTXO? If this were
> possible, the issuer could give the creditor this kind of transaction
> as the guarantee transaction, and in the case a cheat was done, the
> creditor could still use the GT to reallocate that UTXO to themselves.
>
> Now there are issues with this. First of all, it could give anyone the
> ability to double spend. So it would be prudent to limit this in some
> way. The revocation probably should only be valid for up to 6 blocks,
> such that if the transaction has 6 confirmations, it can no longer be
> reallocated (thus preserving the 6 block finality rule). It could also
> be required that the UTXO be marked as opting into this behavior (so
> receivers would know about the possibility it could get revoked). This
> second requirement would require Sabu issuers to make an on-chain
> transaction to set themselves up as an issuer.
>
> Another issue is that this would make it possible for transactions to
> expire. Any claw-back transaction would expire 6 blocks after the
> initial transaction happened. This has been generally avoided in
> bitcoin, but I think the relevant issues are solvable. You can find
> additional discussion of that in this thread [1].
>
> I would imagine this kind of ability would be pretty controversial,
> but since it can close out the possibility for miners to escape
> punishment, it could make this protocol viable.
>
> On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup•net> wrote:
>
>> Hi Erik
>>
>> Please correct me if I misunderstood.
>>
>>> email is fully compromised.
>>
>> What I got is:
>> Email is not good because the sender and receiver are compromised.
>> Email is not good because the message content is revealed.
>> I can claim same argue about any other client/server model. Since
>> the
>> server (website) service provider will ask some sort of KYC. And
>> even if
>> the server uses end-to-end encryption, the provider company still
>> can
>> read the packets content.
>> In my model the passive listener only can discover who is
>> communicate to
>> whom and make a graph of connections. Although it is a threat for
>> privacy but the server/client model has this flaw inherently, since
>> provider already knew everything about everyone. In my model at
>> least
>> users can make some fake connections and send some fake emails in
>> order
>> to inject noise to communications.
>> Please note the fact that entire communication between mobile
>> wallets
>> (via emails) are asymmetric PGP encrypted. The PGP keys are
>> controlled
>> by end users unlike ALL pretending secure messengers (e.g whatsApp,
>> signal, zoom,…).
>> If you are worried about the way of exchanging PGP public key, you
>> are
>> right. The most secure way is in-person PGP key exchanging.
>> After that for payments the wallets communicate in pgp encrypted
>> messages and they can transfer Bitcoin address through an PGP
>> encrypted
>> cipher, thus no revealing Bitcoin address to public would occur.
>> Neither
>> the amounts of transactions will be reviled.
>> There for it would be a good practice for shops to put their email
>> and
>> PGP public key on shop website and/or PGP public key servers,
>> instead of
>> putting Bitcoin address on website or using 3rd parties services to
>> hide
>> their Bitcoin payment addresses.
>>
>> If I missed some points about “fully compromised” please write
>> it to me.
>>
>>> public keys / addresses are sent
>> As I told before ALL communication in Sabu are PGP encrypted.
>>
>>> other routing data encrypted with public keys
>>> (not sure how data is routed in sabu)
>>
>> Sabu is not responsible for routing at all. It simply sends emails.
>> Indeed the wallets peer-to-peer network in Sabu is pretty straight
>> forward. Each mobile wallet has one email address as its handler and
>> identifier in mobile-wallets-network. Each mobile can send message
>> to
>> another mobile by knowing its email address and the PGP public key.
>> This information can be prepared in first face-to-face contact of
>> mobile
>> owners, or later (something like signing the other’s public key in
>> web
>> of trust) when a creditor wants to spend his money and transfer it
>> to
>> another creditor. The creditor1 send the signed money transfer
>> request
>> alongside the email and public key of creditor2 all in a PGP
>> encrypted
>> message to issuer.
>>
>>> separate the Sabu protocol from the app... allow others to
>> implement
>>> desktop version, or other versions that use other routing systems
>>
>> Indeed, it is my approach too. As I told before users will decide
>> between an unstoppable, permission less, self-sovereignty and
>> decentralized pure peer-to-peer communication network (with some
>> resolvable privacy issues) or some efficient, privacy-mimic central
>> limited network.
>>
>>> you can allow direct-entry of a BIP-word-representation
>>> of a public key/address to avoid privacy/central system concerns
>> Agree. Actually, I was thinking about an easy mechanism to share
>> your
>> public key like what you suggested here.
>> But what I consider for a “central system concerns” is the
>> ability of
>> communication without dependency to any company.
>> As an example, what can you do if the twitter bans your account?
>> Nothing! Your content and entire connections will be lost.
>> But if you form your friends list in your mobile (or computer) and
>> have
>> their PGP public keys and they have yours, and use email as a dual
>> purpose tool. First as a handler (the tool for finding and to be
>> found
>> in internet) and second as a communication tool.
>> Thus, no one can stop you, ban you or limit you to send/receive
>> transaction to/from anyone.
>> What I am trying to say is using email is far better than account
>> (username) in a limited central service like twitter, Facebook,
>> telegram... or even in future Sabu servers!
>> You have your connections under your control in your phone. You can
>> easily change your email and use a new email or even a new service
>> provider without losing your connections and your control over it.
>> You just sign your new email address and send it to your friends
>> circle
>> and notify them about changes.
>> Of course, email is not good for millions of followers but it is
>> obviously good for managing your payment network of hundreds of
>> people
>> (either issuers or creditors).
>>
>> Best
>> Raymo
>>
>> On 2021-07-01 20:49, Erik Aronesty wrote:
>>> your protocol should always assume the email system is fully
>>> compromised, and only send public information over email:
>>>
>>> - public keys / addresses are sent
>>> - other routing data encrypted with public keys (not sure how data
>> is
>>> routed in sabu)
>>>
>>> your end user should be able to verify public keys / addresses
>>>
>>> - use QR-codes
>>> - phone calls with users reading BIP words out loud
>>> - other in-person information exchange
>>>
>>> separate the Sabu protocol from the app... allow others to
>> implement
>>> desktop version, or other versions that use other routing systems
>>>
>>> - you can allow direct-entry of a BIP-word-representation of a
>> public
>>> key/address to avoid privacy/central system concerns
>>>
>>> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>> Hi Billy,
>>>> Sorry for late reply. Let’s jump in proposal.
>>>>
>>>>> Some more information about the benefits of this approach vs
>> alternatives (mainly lightning)
>>>> The most important different is unlike the lightning, in Sabu no
>> one
>>>> have to open a channel and pay Bitcoin transaction fee,
>> subsequently no
>>>> one has to close channel and pay another Bitcoin transaction fee.
>> It is
>>>> the huge improvement since it drops the overhead cost of
>> transactions.
>>>> So, it will be more convenience to trade under Sabu protocol.
>>>> In Sabu none of parties of a transaction are obliged to block
>> money in
>>>> any kind of smart contract or any other m of n signature accounts
>>>> on-chain, so it provides more privacy.
>>>> Since Sabu protocol is designed to motivate people to circulate
>>>> transactions (AKA debt documents) in Sabu network, if every actor
>> act
>>>> rationally no one will aware how much money transferred from who
>> to
>>>> whom.
>>>> In case of fraudulent activity by issuer, the creditor will send
>>>> Guarantee Transaction (GT) to Bitcoin network in order to
>> recapture the
>>>> part of his credit. So, in this case the transaction is literally
>>>> recorded on bitcoin blockchain.
>>>> There is only one another reason to recording transaction on
>> Bitcoin
>>>> blockchain. Where one creditor eager to pay Bitcoin transaction
>> fee in
>>>> order to aggregate thousands or even millions different small
>> amount
>>>> debt-documents in a single transaction on Bitcoin blockchain.
>>>> despite these two cases, the rest of transactions all occur in
>> the Sabu
>>>> network (supposed to be over 99%). Thus, no footprint no
>> bottleneck and
>>>> no over process.
>>>>
>>>> Another important power point of Sabu is its pure-peer-to-peer
>> network
>>>> architecture. In Sabu the mobile wallets communicating to each
>> other
>>>> directly without any central server. There is no centralization
>> at all.
>>>> As a result, there will be no routing as well.
>>>> Since only issuer and creditors are aware of the content of
>> transaction
>>>> (who pay how much to whom) it is a huge privacy improvement,
>> which
>>>> doesn’t exist in other layer 2 solutions.
>>>>
>>>> About the usability of Sabu, although the protocol based on the
>>>> collaborating 2 different peer-to-peer network and 3 classic
>>>> server/client networks, but the end user (mobile wallet user)
>> doesn’t
>>>> see any of these complexities.
>>>> The end user simply installs the mobile/desktop wallet and add
>> her/his
>>>> friends to his phonebook by adding their email address or
>> scanning their
>>>> email (and/or PGP public key). After that s/he can immediately
>> start to
>>>> send/receive Bitcoin through Sabu network. Entire communications
>> between
>>>> wallets are PGP encrypted.
>>>> Another good point in Sabu design is, the 12 seed words are using
>> for
>>>> both Bitcoin wallet private key and the PGP private key. So, it
>> is the
>>>> key of user wealth and its identity as well. For more details,
>> please
>>>> read my previous answer to Alex Schoof.
>>>> The issuer, by using his UTXOs and selling them to creditors earn
>> money.
>>>> the issuer creates the debt document (transaction) by which
>> promises to
>>>> creditor an amount of satoshi. These debt documents are valid
>> Bitcoin
>>>> transaction. The only difference is these transactions are
>> intended to
>>>> circulate in Sabu protocol instead of sending to Bitcoin
>> blockchain.
>>>> Each transaction is a small money transfer. 40,000 Satoshi as
>> input and
>>>> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as
>> Bitcoin
>>>> transaction fee.
>>>> The creditors will use these received transactions as money and
>> will pay
>>>> it in exchange of goods or services. For each transaction the
>> creditor
>>>> pays 10 Satoshi as Sabu-transaction-fee to issuer.
>>>> Sabu is not custodial service and the UXTOs are always under
>> issuer
>>>> control, unless issuer or creditor send the signed transaction to
>>>> Bitcoin network. When the transaction was recorded in Bitcoin
>>>> blockchain, the creditor can spend proper UTXO in Bitcoin
>> network.
>>>> Imagine million people use their UTXOs in Sabu, they are issuer
>> and
>>>> issue/update/cancel million transactions per second. All they
>> need is a
>>>> mobile wallet. On the other hand, every one by knowing an issuer
>> can buy
>>>> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and
>> spend
>>>> it, this time Alice really can buy caffe by Bitcoin ;)
>>>> The Bar can install the mobile wallet and every day receives
>> thousands
>>>> of debt documents (transactions), each worth maximum 20,000
>> Satoshi in
>>>> exchange of coffee. And every evening aggregates those small
>>>> transactions to one single transaction and send it to Bitcoin
>> network.
>>>>
>>>>
>>>> The security model of Sabu is pretty straight forward.
>>>> Issuer is the owner of UTXO(s) which will be used in
>> transactions. The
>>>> issuer is and will the only person who creates transactions and
>> sign
>>>> them. The transactions are valid transaction which either issuer
>> or
>>>> creditor can send them to Bitcoin network, but they will never
>> send
>>>> these transactions to Bitcoin network, because of the high
>> Bitcoin
>>>> transaction fee for each single transaction.
>>>> Since issuer is the only one who can sign transaction (spend
>> UTXOs),
>>>> there is a risk of issuer cheating. And no one can stop issuer
>> from
>>>> cheating, because these are his UTXOs and he has the proper
>> private
>>>> keys.
>>>> The Sabu solution is Guarantee transaction. It is a valid
>> transaction
>>>> that issuer has to sign it alongside the Main transaction. In GT
>> both
>>>> issuer and creditor cut a part of their output in favor of
>> Bitcoin
>>>> transaction fee.
>>>> We suppose miners always seeking for more profit, thus in a case
>> there
>>>> are 2 or more transaction are spending same UTXO as input, miner
>> will
>>>> choose transaction with highest feeRate. There is no economically
>>>> benefit for issuer to cheat creditors and pay less transaction
>> fee
>>>> simultaneously. So rationally the issuer won’t cheat creditor.
>>>> It was the simplest explanation of Sabu security model.
>>>>
>>>>> I agree with others that using email is probably not
>> appropriate for a protocol like this. I would highly recommend
>> making your protocol transport-agnostic, allowing users of your
>> protocol to use any transport they want.
>>>> Indeed, the protocol is transparent-agnostic, if I insist of
>> email as a
>>>> user identifier and communicating tool is because of the idea of
>>>> reforming part of internet architecture and make it more
>> decentralized.
>>>> The wallet users can choose classic architecture. In this case
>> mobile
>>>> wallets will connect to a central server and communicate through
>> that
>>>> server (pretty much like all existed mobile wallets). While some
>> users
>>>> decide to use a pure peer-to-peer communication. I knew email has
>> some
>>>> privacy issues but as always it is a tradeoff. Users can decide
>> between
>>>> an unstoppable, permission less, self-sovereignty and
>> decentralized pure
>>>> peer-to-peer communication network (with some resolvable privacy
>> issues)
>>>> or some efficient central limited network.
>>>> Let me know the critics about email. Hopefully this would lead us
>> to
>>>> improve email instead of letting it die. I strongly suggest email
>>>> because it is the ONLY neutral, free “nonproprietary” and
>> open
>>>> protocol/technology for communication in the world that its
>>>> infrastructure is well-established and is accessible all over the
>> glob.
>>>>
>>>> I tried to explain it more, hope was useful. By the way the
>> complete
>>>> explanation is here
>>>>
>>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>>>
>>>>
>>>>
>>>> Regards
>>>> Raymo
>>>>
>>>>
>>>>
>>>> On 2021-06-22 18:20, Billy Tetrud wrote:
>>>>> I would be interested in seeing some more information about the
>>>>> benefits of this approach vs alternatives up front in this
>> write up.
>>>>> Eg how does the security, cost, usability, and privacy compare
>> to the
>>>>> lightning network, which would be the most likely competitor to
>> this
>>>>> idea. It seems clear that there is more counterparty risk here,
>> so it
>>>>> would probably also be very helpful to compare against
>> traditional
>>>>> custodial solutions as well. If you have specific claims on how
>> this
>>>>> system is better than eg lightning in certain contexts, it
>> would be
>>>>> far easier to evaluate the protocol against those claims, and
>> would
>>>>> also be a lot easier for readers to be motivated to read the
>> whole
>>>>> protocol and do a more full analysis.
>>>>>
>>>>> I agree with others that using email is probably not
>> appropriate for a
>>>>> protocol like this. I would highly recommend making your
>> protocol
>>>>> transport-agnostic, allowing users of your protocol to use any
>>>>> transport they want.
>>>>>
>>>>> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
>>>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>
>>>>>> I think you're making a number of assumptions about mining
>> that are
>>>>>> not accurate.
>>>>>>
>>>>>>> First of all, how much chance in finding next block the
>> corrupted
>>>>>> miners have? One percent of all Bitcoin hash powers? Or
>> maximum 5
>>>>>> percent or 10? The cheaters must come up in dividing that 1.2
>>>>>> Bitcoin between. After all the risk/reward must fit them. They
>> can
>>>>>> not be a big mining pool since there is no benefit, so they
>> will be
>>>>>> small miners with low hash rate. If they solve the puzzle and
>>>>>> broadcast the block, no one in the entire Bitcoin network has
>> block
>>>>>> transactions or seen it before in their mempool!
>>>>>>
>>>>>> You're making the assumption that miners won't build on top of
>> a
>>>>>> block
>>>>>> with transactions they have not seen before or transactions
>> that may
>>>>>> contain double spends of unconfirmed inputs, this is not how
>> mining
>>>>>> works, as long as the block passes the consensus rules
>> effectively
>>>>>> all
>>>>>> miners will mine on top of it by default, this behavior is
>>>>>> fundamental
>>>>>> to how mining currently works and is fairly deeply baked into
>> the
>>>>>> current mining infrastructure.
>>>>>>
>>>>>>> Will they accept this block? In theory it is possible and
>> have
>>>>>> 0.01 percent chance but we can eliminate this small
>> possibilities by
>>>>>> a simple BIP for miners.
>>>>>>
>>>>>> What would this BIP look like? I don't see how this could work
>> in a
>>>>>> decentralized way as you would need another way of reaching
>>>>>> consensus
>>>>>> on what defines a valid block. Right now the chance is nearly
>> 100
>>>>>> percent that a miner will mine on top of the latest valid
>> block,
>>>>>> many
>>>>>> pools(most last I checked) will even mine on the next block
>> before
>>>>>> they validate the latest block fully(ie validationless mining)
>> to
>>>>>> reduce their orphan rates.
>>>>>>
>>>>>>> We suppose the miners always control transactions with
>>>>>> doc-watchers and avoid accepting transaction with same UTXO
>> but
>>>>>> different output.
>>>>>>
>>>>>> Miners have different mempool policy/rules for what
>> transactions
>>>>>> they
>>>>>> themselves mine but all miners must mine on the most work
>> chain of
>>>>>> valid blocks otherwise they risk their own blocks being
>> orphaned,
>>>>>> any
>>>>>> miner that does not do this is effectively guaranteed to have
>> their
>>>>>> block orphaned right now.
>>>>>>
>>>>>>> Because of high Bitcoin transaction fee, this guarantee
>>>>>> transaction will take place in next block, even if other
>> transaction
>>>>>> which are using the same UTXO as input existed in mempool.
>>>>>>
>>>>>> When a new transaction is broadcast miners do not immediately
>> start
>>>>>> mining on a block template that includes that transaction, the
>>>>>> template won't even be generated immediately when it enters a
>> miners
>>>>>> mempool in practice, for bandwidth/network efficiency reasons
>> mining
>>>>>> pools batch update the stratum templates/jobs they mine
>> against so
>>>>>> there can be significant latency between the time a
>> transaction is
>>>>>> actually broadcast and hits the miners mempool and the time
>> the
>>>>>> miners
>>>>>> actually switch to mining on top it, these batched updates are
>>>>>> essentially like point in time snapshots of the mempool and
>>>>>> typically
>>>>>> remain valid(as in the pool will accept shares submitted
>> against
>>>>>> that
>>>>>> job as valid) until the bitcoin network finds the next block.
>> I
>>>>>> don't
>>>>>> think these batch updates are done more often than every 30
>> seconds
>>>>>> typically, while often it is on the order of multiple minutes
>>>>>> depending on the pool.
>>>>>>
>>>>>> Regards,
>>>>>> James
>>>>>>
>>>>>> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
>>>>>> <bitcoin-dev@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@lists•linuxfoundation.org
>>>>>>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-03 8:02 ` raymo
@ 2021-07-07 3:20 ` Billy Tetrud
2021-07-17 15:50 ` raymo
0 siblings, 1 reply; 41+ messages in thread
From: Billy Tetrud @ 2021-07-07 3:20 UTC (permalink / raw)
To: raymo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 39831 bytes --]
> As far as I know the “claw back” mechanism doesn’t exist in Bitcoin
system, and probably most Bitcoiners won’t be agree on it.
It certainly doesn't. And it would definitely be a hard sell.
> It looks the miners still can abuse Sabu, but as I told before the miner
or better say the mining pool must be issuer .. or must be creditor .. or
collaborate one of them in a
conspiracy.
Yes. But it certainly incentivizes miners to become creditors and scam
people. Even if a small miner who mines one block a year does this, they
can mine all Guarantee Transactions in their possession. Larger miners that
mine one block every few days can scam that much more often. Even with $5
credits, that could be an extra $9000 gained in a block. That's pretty
substantial when fees are totaling around $45,000 per block.
> would be resolved by a slightly upgrade in Bitcoin protocol by applying
the BIPxxx “for flagging/unflagging promised UTXOs”
As others have mentioned tho, doing something like that would be at very
least quite complex, and at worst impossible to do securely. The whole
reason why bitcoin's blockchain exists in the first place is to be a single
source of truth for transactions. The mempool is not a source of truth for
consensus. The Sabu network could not be a source of truth either for
consensus, without some serious innovations (that may not be possible). It
isn't as simple as you seem to be thinking.
> The new transaction will use same 40,000 UTXO as input and the outputs
will be 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee)
4,500 Sat for creditor 2
This is the part I was unable to find/understand quickly enough in the
original write up. So for creditor 1 to pay creditor 2, a new main
transaction and guarantee transaction are created that credit the
appropriate people, right? FYI, the MT and GT acronyms make it harder for
me to read/understand, so I'm preferring to write them out. But that helps.
Let me write this out in a different (more compact) way:
1. Creditor A $5 -> Issuer
2. Issuer creates and shares transactions:
Main Transaction (40k sats):
* Issuer: 19k sats
* Creditor A: 11k sats
* Fee: 10k sats (4k from creditor, 6k from issuer)
Guarantee Transaction (40k sats):
* Issuer: 13,300 sats
* Creditor A: 1650 sats
* Fee: 25,050 sats
3. Creditor A, 6k sats -> Creditor B. Issuer creates and shares
transactions:
Main Transaction (40k sats):
* Issuer: 19k sats
* Creditor A: 6,500 sats
* Creditor B: 4,500 sats
* Fee: 10k sats (4k from creditor, 6k from issuer)
Guarantee Transaction (40k sats):
* Issuer: 13300 sats
* Creditor A: 975 sats
* Creditor B: 675 sats
* Fee: 25050 sats
Is this right?
> The miner attack is just a failed plan as I explained before
I thought you acknowledged that the miner attack is an issue above. No?
>> Sabu has slightly greater risk comparing lightning
> It is not true,
What I mean is that a violation of trust results in more damaging effects
with Sabu than with lightning. In lightning, if your channel partner
cheats, at worst you must simply pay a normal transaction fee. With Sabu,
if a creditor cheats, you will likely pay an abnormally large transaction
fee. This is what I mean by "greater risk". Some attackers are what's known
as griefers - these are people willing to spend time and money hurting
someone else, even if they don't make a profit from it (other
than schadenfreude). It seems clear there is a greater risk of being
griefed in Sabu than in lightning.
Furthermore, while in lightning, if you perform the protocol properly, your
funds can never be stolen except in very extreme circumstances (eg
widespread long-running network congestion that prevents confirming a
revoke transaction). By contrast, Sabu has a significant likelihood that a
cheating transaction could be mined instead of the guarantee transaction.
Perhaps the likelihood is approximately 2 seconds / 10 minutes (0.3%
chance), but a 0.3% is clearly larger than approximately 0% chance in
lightning. Again, this is another part of what I mean by "higher risk".
These are both real counterparty risks that you shouldn't simply ignore. It
may be true that no rational actor will attempt an attack, however not all
actors are rational. People also make mistakes, write buggy software, etc
etc. The existence of risk doesn't ruin your idea - every protocol has
risks. But identifying the specific risks is the only way to compare the
properties against alternatives (like on chain transactions or the
lightning network). I think its important to acknowledge these risks in
your write up.
> I explained before this kind of attacks will not happened never
If people use your protocol, some will inevitably use it wrong. Those that
use it wrong should be the ones that pay the price for it - but it is a
downside of the protocol if the counter party of the person that makes a
mistake (or attempts something malicious) is harmed as a result. Again,
these kinds of trade offs are ok, but you should not be assuming that
attacks like this will never happen. They will happen sometimes. You must
assume that. The question is what is the result when an attack is
attempted? And how will that affect what kinds of actors will attempt an
attack (malicious, profit seeking, honest, stupid, wreckless, incompetent,
other types of actors etc etc)?
> I didn’t find any case Lightning can compete with Sabu.
As I explained above related to risk, there are trade offs. I would like to
see in your write up a clear list of these trade offs. The additional risk
(as I explained it above) is one trade off. It sounds like there are limits
in which a creditor or issuer can safely rely on incentives to prevent
attacks. Did you specify what those limits are? The Lightning network also
has limits - eg a lightning node can't allow its channel partner to spend
100% of their coins without taking on additional risk of attack. How do
those limits compare in Sabu? For example, an issuer couldn't allow any
creditor to spend so much of their credited bitcoin that their credit goes
below the amount they would receive in any past Guarantee Transaction
without taking on the risk that the creditor would post that guarantee
transaction and receive coins they shouldn't own anymore. I would love to
see a more detailed comparison of Sabu to lightning.
If your protocol works out, there are obvious benefits: transactions that
could be done with no on-chain footprint. However, even if the protocol
works out, there are trade offs and those trade offs should be made very
clear. Even if the comparative downsides are small.
~BT
Hi Billy
> > high-level overview of how all the pieces (How Sabu protocol works).
> > how normal transactions happen in their entirety.
> Ok, lets re-explain Sabu. In Sabu protocol we have two type of actors.
> The issuers who own Bitcoin (they own UTXOs on Bitcoin blockchain), and
> the creditors who will own Bitcoins (the UTXOs on Bitcoin blockchain),
> if the issuer or the creditor sends the prepared transaction to Bitcoin
> network. But for know creditors have the transaction in their hand.
> Before sending this transaction to Bitcoin network it acts (in Sabu
> protocol and Sabu network) as a liability of issuer.
> The story always starts from issuer, the person who get money or goods
> or services from a creditor and in exchange creates and sings a valid
> Bitcoin transaction by which the issuer spends his UTXO and as a one of
> the outputs of the transaction, there will be an output for creditor’s
> address equal to the money issuer already get paid.
> This transaction is a valid transaction which is signed “only” by
> issuer. The outputs of transaction are just and exact balance of the
> parties (issuer and creditor).
> Lets, imagine the creditor payed 5$ (almost equal to 15,000 Sat) to
> issuer. Thus, issuer will create and sign a transaction by which he
> spends 40,000 Sat and the outputs will be
> 11,000 for creditor (the creditor has to pay 4,000 Sat in favor of
> transaction fee),
> 10,000 for Bitcoin-transaction-fee (4,000 by creditor and 6,000 by
> issuer) and
> 19,000 change back to issuer account address.
> It is our Main Transaction (MT) which is a pretty normal and valid
> transaction.
> Alongside the MT, issuer creates and signs a Guarantee Transaction (GT).
> In GT issuer spends same 40,000 Sat UTXO as input, and as outputs
> the creditor will get 15% of his 11,000 Sat in Main Transaction. Thus
> the creditor output will be 1,650 Sat and the rest of creditor’s money
> (11,000 – 1,650 = 9,350 Sat) will be added to transaction fee.
> In GT also issuer will lose a part of his money. New output for issuer
> will be 19,000 * 70% = 13,300 and the rest will be added to transaction
> fee (19,000 – 13,300 = 5,700 Sat)
> Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =
> 25,050 Sat
> Now the creditor has 2 valid transactions (MT and GT) in his hands. He
> can send either MT or GT or both to Bitcoin Network. But in all cases,
> he will lose a portion of his money in favor of transaction fee (miner’s
> income). So, rationally he will never send transactions to Bitcoin
> network unless he wants consciously hurt himself.
> The creditor always prefers to spend his credit inside the Sabu
> protocol. It is “how normal transactions happen in their entirety.”
> Creditor has equal to 15,000 Sat credit. Say he wants to buy a caffe
> worth 6,000 Sat. He has to ask the issuer to nullify previous MT and GT,
> and create and sign new transaction and cut 6,000 Sat from his credit
> and transfer it to a new creditor (say C2).
> The new transaction will use same 40,000 UTXO as input and the outputs
> will be
> 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee)
> 4,500 Sat for creditor 2 (he has to pay 1,500 Sat for transaction fee as
> well)
> 10,000 for Bitcoin-transaction-fee (4,000 by two creditors and 6,000 by
> issuer) and
> 19,000 change back to issuer account address.
> This is the new MT, and as you can see the C1 and C2 have their new
> credit in transaction.
> You can calculate the new GT as well.
> Note: due to simplicity I just rounded the numbers and skipped the
> Sabu-transaction-fee
> I just wrote this long story to explain how creditors just transfer
> money in between.
> If we take a snapshot of Sabu network, we will see millions of valid
> transactions flowing in network and none of the issuers or creditors
> will send these transactions to Bitcoin network due the transaction fee,
> while in Bitcoin blockchain nothing is changed! The UTXOs are untouched,
> and no one can say which UTXO is promised to who.
> It is a pretty secure off-chain protocol.
> Although I expected more Bitcoiners to react about Sabu proposal and
> comment for or against it, so far, I have not seen any serious criticism
> or real threat about protocol.
> The miner attack is just a failed plan as I explained before.
> > Sabu has slightly greater risk comparing lightning
> It is not true, since creditors can manage they risk, and limit their
> credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor to
> accept more liability from issuers or not.
> The creditor can keep his credit around a fix number. That is, the
> creditor spends a part of his credit and then again increase its credit.
> Let imagine you already payed 5$ to a issuer and you got 15,000 Sat
> credit in your wallet. So, you will spend this 15,000 Sat (buy coffee,
> ice-cream, etc.) till your wallet run out of Satoshi and again you will
> pay another 5$ to issuer and get new 15,000 sat credit. Since all of
> these transactions has near zero cost you are not obliged to charge your
> wallet 200$ in one shot.
> It is absolutely low risk deal. In worst case the creditor (you) will
> lose 5$. And as I explained before this kind of attacks will not
> happened never. And as you told Sabu provides cheaper and a larger
> number of transactions.
> > This would be essentially worse than the lightning network in some ways,
> Disagree! Please explain the scenario exactly. I didn’t find any case
> Lightning can compete with Sabu.
> > ledger of accounts and their balances, along with proof that the entity
> owns…
> It is almost what I designed in Sabu. They are doc-watcher servers. They
> are a set of records of UTXOs and the proper Merkle root hash of related
> transaction in Sabu network. The intention was stopping issuer from
> spend and promises same UTXO to different people (that they are not
> aware of the existence of the other). So, any individual creditor (or
> their software) could verify that total liabilities (in account
> balances) are less than the half of the total bitcoins the entity owns.
> And if something doesn't match up, they won’t yell, instead they refuse
> the deal in first place, or send the GT to Bitcoin network and hurt the
> cheater issuer by slashing his money. it is “Tit-for-tat”.
> > I think it likely has critical security holes. Perhaps you can fix them!
> There is no critical security hole. Please refer it by facts, numbers
> and proves.
> I think I already fixed all critics.
>
> Billy! I am actively working on this proposal and if no one cannot show
> a real problem or security issue in the project, I will start
> implementing it.
> Just imagine people regularly using Sabu protocol and send/receive
> Bitcoin (Satoshi) in billions of small amount transactions every day.
> This protocol will outspread Bitcoin and will attract a new crowd of
> penny investors to Bitcoin. The people who can afford 20$ or less
> monthly to invest on Bitcoin.
> Sabu brings Bitcoin to a whole new life.
> It will be the true scalable and mass adaption, and I do not know how to
> attract more real Bitcoin fans to this proposal!
> Guys! Here is the Bitcoin renascence.
> Maybe you can help it.
> Regards
> Raymo
On Sat, Jul 3, 2021 at 1:02 AM <raymo@riseup•net> wrote:
> Hi Billy,
>
> > What if it was possible for the creditor to claw back the funds
> As far as I know the “claw back” mechanism doesn’t exist in Bitcoin
> system, and probably most Bitcoiners won’t be agree on it.
> Even if we want to add claw back to Bitcoin in general, and Sabu in
> particular, it would add too complexities and uncertainty to Bitcoin.
> So, it would be better to not touch that part, instead focusing on
> reduce the cheating risk by putting some penalty for both issuers,
> creditors and miners.
> We already have the penalties for both issuers and creditors.
> It looks the miners still can abuse Sabu, but as I told before the miner
> or better say the mining pool must be issuer (to be able to sign the
> promised UTXO in cheating way) or must be creditor (in order to have a
> copy of GT and not lose his money in favor of a stranger miner. Remember
> the fact that creditor will lose 70% of their money in favor of Bitcoin
> transaction fee in a typical GT) or collaborate one of them in a
> conspiracy. Otherwise, there will be no economic benefit in this attack.
>
> All these 3 cases of the attacks, theoretically could be happened, but
> the risk to reward ratio is enough high to hinder potential malevolent
> from a practical act.
> Even this very small risk of miner attacks (which don’t care the attack
> costs, since he is not interested in economic benefit, but he wants to
> ruin Sabu), would be resolved by a slightly upgrade in Bitcoin protocol
> by applying the BIPxxx “for flagging/unflagging promised UTXOs”.
> I am not in rush to apply this upgrade on Bitcoin protocol, instead I am
> actively working in order to realize the Sabu protocol and Gazin wallet.
> Later the Sabu community will carry the BIPxxx.
>
> Best
>
> On 2021-07-02 17:57, Billy Tetrud wrote:
> > Thanks for the details Raymo. A thought occurred to me. Given the fact
> > that miners can abuse this system without penalty, it would be useful
> > to be able to fix this. What if it was possible for the creditor to
> > claw back the funds even if the cheating transaction was mined instead
> > of the guarantee transaction? Let's say there was a way to sign a
> > transaction that gives the receiver of that transaction the ability to
> > override any other transaction that uses the UTXO? If this were
> > possible, the issuer could give the creditor this kind of transaction
> > as the guarantee transaction, and in the case a cheat was done, the
> > creditor could still use the GT to reallocate that UTXO to themselves.
> >
> > Now there are issues with this. First of all, it could give anyone the
> > ability to double spend. So it would be prudent to limit this in some
> > way. The revocation probably should only be valid for up to 6 blocks,
> > such that if the transaction has 6 confirmations, it can no longer be
> > reallocated (thus preserving the 6 block finality rule). It could also
> > be required that the UTXO be marked as opting into this behavior (so
> > receivers would know about the possibility it could get revoked). This
> > second requirement would require Sabu issuers to make an on-chain
> > transaction to set themselves up as an issuer.
> >
> > Another issue is that this would make it possible for transactions to
> > expire. Any claw-back transaction would expire 6 blocks after the
> > initial transaction happened. This has been generally avoided in
> > bitcoin, but I think the relevant issues are solvable. You can find
> > additional discussion of that in this thread [1].
> >
> > I would imagine this kind of ability would be pretty controversial,
> > but since it can close out the possibility for miners to escape
> > punishment, it could make this protocol viable.
> >
> > On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup•net> wrote:
> >
> >> Hi Erik
> >>
> >> Please correct me if I misunderstood.
> >>
> >>> email is fully compromised.
> >>
> >> What I got is:
> >> Email is not good because the sender and receiver are compromised.
> >> Email is not good because the message content is revealed.
> >> I can claim same argue about any other client/server model. Since
> >> the
> >> server (website) service provider will ask some sort of KYC. And
> >> even if
> >> the server uses end-to-end encryption, the provider company still
> >> can
> >> read the packets content.
> >> In my model the passive listener only can discover who is
> >> communicate to
> >> whom and make a graph of connections. Although it is a threat for
> >> privacy but the server/client model has this flaw inherently, since
> >> provider already knew everything about everyone. In my model at
> >> least
> >> users can make some fake connections and send some fake emails in
> >> order
> >> to inject noise to communications.
> >> Please note the fact that entire communication between mobile
> >> wallets
> >> (via emails) are asymmetric PGP encrypted. The PGP keys are
> >> controlled
> >> by end users unlike ALL pretending secure messengers (e.g whatsApp,
> >> signal, zoom,…).
> >> If you are worried about the way of exchanging PGP public key, you
> >> are
> >> right. The most secure way is in-person PGP key exchanging.
> >> After that for payments the wallets communicate in pgp encrypted
> >> messages and they can transfer Bitcoin address through an PGP
> >> encrypted
> >> cipher, thus no revealing Bitcoin address to public would occur.
> >> Neither
> >> the amounts of transactions will be reviled.
> >> There for it would be a good practice for shops to put their email
> >> and
> >> PGP public key on shop website and/or PGP public key servers,
> >> instead of
> >> putting Bitcoin address on website or using 3rd parties services to
> >> hide
> >> their Bitcoin payment addresses.
> >>
> >> If I missed some points about “fully compromised” please write
> >> it to me.
> >>
> >>> public keys / addresses are sent
> >> As I told before ALL communication in Sabu are PGP encrypted.
> >>
> >>> other routing data encrypted with public keys
> >>> (not sure how data is routed in sabu)
> >>
> >> Sabu is not responsible for routing at all. It simply sends emails.
> >> Indeed the wallets peer-to-peer network in Sabu is pretty straight
> >> forward. Each mobile wallet has one email address as its handler and
> >> identifier in mobile-wallets-network. Each mobile can send message
> >> to
> >> another mobile by knowing its email address and the PGP public key.
> >> This information can be prepared in first face-to-face contact of
> >> mobile
> >> owners, or later (something like signing the other’s public key in
> >> web
> >> of trust) when a creditor wants to spend his money and transfer it
> >> to
> >> another creditor. The creditor1 send the signed money transfer
> >> request
> >> alongside the email and public key of creditor2 all in a PGP
> >> encrypted
> >> message to issuer.
> >>
> >>> separate the Sabu protocol from the app... allow others to
> >> implement
> >>> desktop version, or other versions that use other routing systems
> >>
> >> Indeed, it is my approach too. As I told before users will decide
> >> between an unstoppable, permission less, self-sovereignty and
> >> decentralized pure peer-to-peer communication network (with some
> >> resolvable privacy issues) or some efficient, privacy-mimic central
> >> limited network.
> >>
> >>> you can allow direct-entry of a BIP-word-representation
> >>> of a public key/address to avoid privacy/central system concerns
> >> Agree. Actually, I was thinking about an easy mechanism to share
> >> your
> >> public key like what you suggested here.
> >> But what I consider for a “central system concerns” is the
> >> ability of
> >> communication without dependency to any company.
> >> As an example, what can you do if the twitter bans your account?
> >> Nothing! Your content and entire connections will be lost.
> >> But if you form your friends list in your mobile (or computer) and
> >> have
> >> their PGP public keys and they have yours, and use email as a dual
> >> purpose tool. First as a handler (the tool for finding and to be
> >> found
> >> in internet) and second as a communication tool.
> >> Thus, no one can stop you, ban you or limit you to send/receive
> >> transaction to/from anyone.
> >> What I am trying to say is using email is far better than account
> >> (username) in a limited central service like twitter, Facebook,
> >> telegram... or even in future Sabu servers!
> >> You have your connections under your control in your phone. You can
> >> easily change your email and use a new email or even a new service
> >> provider without losing your connections and your control over it.
> >> You just sign your new email address and send it to your friends
> >> circle
> >> and notify them about changes.
> >> Of course, email is not good for millions of followers but it is
> >> obviously good for managing your payment network of hundreds of
> >> people
> >> (either issuers or creditors).
> >>
> >> Best
> >> Raymo
> >>
> >> On 2021-07-01 20:49, Erik Aronesty wrote:
> >>> your protocol should always assume the email system is fully
> >>> compromised, and only send public information over email:
> >>>
> >>> - public keys / addresses are sent
> >>> - other routing data encrypted with public keys (not sure how data
> >> is
> >>> routed in sabu)
> >>>
> >>> your end user should be able to verify public keys / addresses
> >>>
> >>> - use QR-codes
> >>> - phone calls with users reading BIP words out loud
> >>> - other in-person information exchange
> >>>
> >>> separate the Sabu protocol from the app... allow others to
> >> implement
> >>> desktop version, or other versions that use other routing systems
> >>>
> >>> - you can allow direct-entry of a BIP-word-representation of a
> >> public
> >>> key/address to avoid privacy/central system concerns
> >>>
> >>> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
> >>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>>>
> >>>> Hi Billy,
> >>>> Sorry for late reply. Let’s jump in proposal.
> >>>>
> >>>>> Some more information about the benefits of this approach vs
> >> alternatives (mainly lightning)
> >>>> The most important different is unlike the lightning, in Sabu no
> >> one
> >>>> have to open a channel and pay Bitcoin transaction fee,
> >> subsequently no
> >>>> one has to close channel and pay another Bitcoin transaction fee.
> >> It is
> >>>> the huge improvement since it drops the overhead cost of
> >> transactions.
> >>>> So, it will be more convenience to trade under Sabu protocol.
> >>>> In Sabu none of parties of a transaction are obliged to block
> >> money in
> >>>> any kind of smart contract or any other m of n signature accounts
> >>>> on-chain, so it provides more privacy.
> >>>> Since Sabu protocol is designed to motivate people to circulate
> >>>> transactions (AKA debt documents) in Sabu network, if every actor
> >> act
> >>>> rationally no one will aware how much money transferred from who
> >> to
> >>>> whom.
> >>>> In case of fraudulent activity by issuer, the creditor will send
> >>>> Guarantee Transaction (GT) to Bitcoin network in order to
> >> recapture the
> >>>> part of his credit. So, in this case the transaction is literally
> >>>> recorded on bitcoin blockchain.
> >>>> There is only one another reason to recording transaction on
> >> Bitcoin
> >>>> blockchain. Where one creditor eager to pay Bitcoin transaction
> >> fee in
> >>>> order to aggregate thousands or even millions different small
> >> amount
> >>>> debt-documents in a single transaction on Bitcoin blockchain.
> >>>> despite these two cases, the rest of transactions all occur in
> >> the Sabu
> >>>> network (supposed to be over 99%). Thus, no footprint no
> >> bottleneck and
> >>>> no over process.
> >>>>
> >>>> Another important power point of Sabu is its pure-peer-to-peer
> >> network
> >>>> architecture. In Sabu the mobile wallets communicating to each
> >> other
> >>>> directly without any central server. There is no centralization
> >> at all.
> >>>> As a result, there will be no routing as well.
> >>>> Since only issuer and creditors are aware of the content of
> >> transaction
> >>>> (who pay how much to whom) it is a huge privacy improvement,
> >> which
> >>>> doesn’t exist in other layer 2 solutions.
> >>>>
> >>>> About the usability of Sabu, although the protocol based on the
> >>>> collaborating 2 different peer-to-peer network and 3 classic
> >>>> server/client networks, but the end user (mobile wallet user)
> >> doesn’t
> >>>> see any of these complexities.
> >>>> The end user simply installs the mobile/desktop wallet and add
> >> her/his
> >>>> friends to his phonebook by adding their email address or
> >> scanning their
> >>>> email (and/or PGP public key). After that s/he can immediately
> >> start to
> >>>> send/receive Bitcoin through Sabu network. Entire communications
> >> between
> >>>> wallets are PGP encrypted.
> >>>> Another good point in Sabu design is, the 12 seed words are using
> >> for
> >>>> both Bitcoin wallet private key and the PGP private key. So, it
> >> is the
> >>>> key of user wealth and its identity as well. For more details,
> >> please
> >>>> read my previous answer to Alex Schoof.
> >>>> The issuer, by using his UTXOs and selling them to creditors earn
> >> money.
> >>>> the issuer creates the debt document (transaction) by which
> >> promises to
> >>>> creditor an amount of satoshi. These debt documents are valid
> >> Bitcoin
> >>>> transaction. The only difference is these transactions are
> >> intended to
> >>>> circulate in Sabu protocol instead of sending to Bitcoin
> >> blockchain.
> >>>> Each transaction is a small money transfer. 40,000 Satoshi as
> >> input and
> >>>> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as
> >> Bitcoin
> >>>> transaction fee.
> >>>> The creditors will use these received transactions as money and
> >> will pay
> >>>> it in exchange of goods or services. For each transaction the
> >> creditor
> >>>> pays 10 Satoshi as Sabu-transaction-fee to issuer.
> >>>> Sabu is not custodial service and the UXTOs are always under
> >> issuer
> >>>> control, unless issuer or creditor send the signed transaction to
> >>>> Bitcoin network. When the transaction was recorded in Bitcoin
> >>>> blockchain, the creditor can spend proper UTXO in Bitcoin
> >> network.
> >>>> Imagine million people use their UTXOs in Sabu, they are issuer
> >> and
> >>>> issue/update/cancel million transactions per second. All they
> >> need is a
> >>>> mobile wallet. On the other hand, every one by knowing an issuer
> >> can buy
> >>>> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and
> >> spend
> >>>> it, this time Alice really can buy caffe by Bitcoin ;)
> >>>> The Bar can install the mobile wallet and every day receives
> >> thousands
> >>>> of debt documents (transactions), each worth maximum 20,000
> >> Satoshi in
> >>>> exchange of coffee. And every evening aggregates those small
> >>>> transactions to one single transaction and send it to Bitcoin
> >> network.
> >>>>
> >>>>
> >>>> The security model of Sabu is pretty straight forward.
> >>>> Issuer is the owner of UTXO(s) which will be used in
> >> transactions. The
> >>>> issuer is and will the only person who creates transactions and
> >> sign
> >>>> them. The transactions are valid transaction which either issuer
> >> or
> >>>> creditor can send them to Bitcoin network, but they will never
> >> send
> >>>> these transactions to Bitcoin network, because of the high
> >> Bitcoin
> >>>> transaction fee for each single transaction.
> >>>> Since issuer is the only one who can sign transaction (spend
> >> UTXOs),
> >>>> there is a risk of issuer cheating. And no one can stop issuer
> >> from
> >>>> cheating, because these are his UTXOs and he has the proper
> >> private
> >>>> keys.
> >>>> The Sabu solution is Guarantee transaction. It is a valid
> >> transaction
> >>>> that issuer has to sign it alongside the Main transaction. In GT
> >> both
> >>>> issuer and creditor cut a part of their output in favor of
> >> Bitcoin
> >>>> transaction fee.
> >>>> We suppose miners always seeking for more profit, thus in a case
> >> there
> >>>> are 2 or more transaction are spending same UTXO as input, miner
> >> will
> >>>> choose transaction with highest feeRate. There is no economically
> >>>> benefit for issuer to cheat creditors and pay less transaction
> >> fee
> >>>> simultaneously. So rationally the issuer won’t cheat creditor.
> >>>> It was the simplest explanation of Sabu security model.
> >>>>
> >>>>> I agree with others that using email is probably not
> >> appropriate for a protocol like this. I would highly recommend
> >> making your protocol transport-agnostic, allowing users of your
> >> protocol to use any transport they want.
> >>>> Indeed, the protocol is transparent-agnostic, if I insist of
> >> email as a
> >>>> user identifier and communicating tool is because of the idea of
> >>>> reforming part of internet architecture and make it more
> >> decentralized.
> >>>> The wallet users can choose classic architecture. In this case
> >> mobile
> >>>> wallets will connect to a central server and communicate through
> >> that
> >>>> server (pretty much like all existed mobile wallets). While some
> >> users
> >>>> decide to use a pure peer-to-peer communication. I knew email has
> >> some
> >>>> privacy issues but as always it is a tradeoff. Users can decide
> >> between
> >>>> an unstoppable, permission less, self-sovereignty and
> >> decentralized pure
> >>>> peer-to-peer communication network (with some resolvable privacy
> >> issues)
> >>>> or some efficient central limited network.
> >>>> Let me know the critics about email. Hopefully this would lead us
> >> to
> >>>> improve email instead of letting it die. I strongly suggest email
> >>>> because it is the ONLY neutral, free “nonproprietary” and
> >> open
> >>>> protocol/technology for communication in the world that its
> >>>> infrastructure is well-established and is accessible all over the
> >> glob.
> >>>>
> >>>> I tried to explain it more, hope was useful. By the way the
> >> complete
> >>>> explanation is here
> >>>>
> >>
> >
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> >>>>
> >>>>
> >>>>
> >>>> Regards
> >>>> Raymo
> >>>>
> >>>>
> >>>>
> >>>> On 2021-06-22 18:20, Billy Tetrud wrote:
> >>>>> I would be interested in seeing some more information about the
> >>>>> benefits of this approach vs alternatives up front in this
> >> write up.
> >>>>> Eg how does the security, cost, usability, and privacy compare
> >> to the
> >>>>> lightning network, which would be the most likely competitor to
> >> this
> >>>>> idea. It seems clear that there is more counterparty risk here,
> >> so it
> >>>>> would probably also be very helpful to compare against
> >> traditional
> >>>>> custodial solutions as well. If you have specific claims on how
> >> this
> >>>>> system is better than eg lightning in certain contexts, it
> >> would be
> >>>>> far easier to evaluate the protocol against those claims, and
> >> would
> >>>>> also be a lot easier for readers to be motivated to read the
> >> whole
> >>>>> protocol and do a more full analysis.
> >>>>>
> >>>>> I agree with others that using email is probably not
> >> appropriate for a
> >>>>> protocol like this. I would highly recommend making your
> >> protocol
> >>>>> transport-agnostic, allowing users of your protocol to use any
> >>>>> transport they want.
> >>>>>
> >>>>> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
> >>>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>>>>
> >>>>>> I think you're making a number of assumptions about mining
> >> that are
> >>>>>> not accurate.
> >>>>>>
> >>>>>>> First of all, how much chance in finding next block the
> >> corrupted
> >>>>>> miners have? One percent of all Bitcoin hash powers? Or
> >> maximum 5
> >>>>>> percent or 10? The cheaters must come up in dividing that 1.2
> >>>>>> Bitcoin between. After all the risk/reward must fit them. They
> >> can
> >>>>>> not be a big mining pool since there is no benefit, so they
> >> will be
> >>>>>> small miners with low hash rate. If they solve the puzzle and
> >>>>>> broadcast the block, no one in the entire Bitcoin network has
> >> block
> >>>>>> transactions or seen it before in their mempool!
> >>>>>>
> >>>>>> You're making the assumption that miners won't build on top of
> >> a
> >>>>>> block
> >>>>>> with transactions they have not seen before or transactions
> >> that may
> >>>>>> contain double spends of unconfirmed inputs, this is not how
> >> mining
> >>>>>> works, as long as the block passes the consensus rules
> >> effectively
> >>>>>> all
> >>>>>> miners will mine on top of it by default, this behavior is
> >>>>>> fundamental
> >>>>>> to how mining currently works and is fairly deeply baked into
> >> the
> >>>>>> current mining infrastructure.
> >>>>>>
> >>>>>>> Will they accept this block? In theory it is possible and
> >> have
> >>>>>> 0.01 percent chance but we can eliminate this small
> >> possibilities by
> >>>>>> a simple BIP for miners.
> >>>>>>
> >>>>>> What would this BIP look like? I don't see how this could work
> >> in a
> >>>>>> decentralized way as you would need another way of reaching
> >>>>>> consensus
> >>>>>> on what defines a valid block. Right now the chance is nearly
> >> 100
> >>>>>> percent that a miner will mine on top of the latest valid
> >> block,
> >>>>>> many
> >>>>>> pools(most last I checked) will even mine on the next block
> >> before
> >>>>>> they validate the latest block fully(ie validationless mining)
> >> to
> >>>>>> reduce their orphan rates.
> >>>>>>
> >>>>>>> We suppose the miners always control transactions with
> >>>>>> doc-watchers and avoid accepting transaction with same UTXO
> >> but
> >>>>>> different output.
> >>>>>>
> >>>>>> Miners have different mempool policy/rules for what
> >> transactions
> >>>>>> they
> >>>>>> themselves mine but all miners must mine on the most work
> >> chain of
> >>>>>> valid blocks otherwise they risk their own blocks being
> >> orphaned,
> >>>>>> any
> >>>>>> miner that does not do this is effectively guaranteed to have
> >> their
> >>>>>> block orphaned right now.
> >>>>>>
> >>>>>>> Because of high Bitcoin transaction fee, this guarantee
> >>>>>> transaction will take place in next block, even if other
> >> transaction
> >>>>>> which are using the same UTXO as input existed in mempool.
> >>>>>>
> >>>>>> When a new transaction is broadcast miners do not immediately
> >> start
> >>>>>> mining on a block template that includes that transaction, the
> >>>>>> template won't even be generated immediately when it enters a
> >> miners
> >>>>>> mempool in practice, for bandwidth/network efficiency reasons
> >> mining
> >>>>>> pools batch update the stratum templates/jobs they mine
> >> against so
> >>>>>> there can be significant latency between the time a
> >> transaction is
> >>>>>> actually broadcast and hits the miners mempool and the time
> >> the
> >>>>>> miners
> >>>>>> actually switch to mining on top it, these batched updates are
> >>>>>> essentially like point in time snapshots of the mempool and
> >>>>>> typically
> >>>>>> remain valid(as in the pool will accept shares submitted
> >> against
> >>>>>> that
> >>>>>> job as valid) until the bitcoin network finds the next block.
> >> I
> >>>>>> don't
> >>>>>> think these batch updates are done more often than every 30
> >> seconds
> >>>>>> typically, while often it is on the order of multiple minutes
> >>>>>> depending on the pool.
> >>>>>>
> >>>>>> Regards,
> >>>>>> James
> >>>>>>
> >>>>>> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> >>>>>> <bitcoin-dev@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@lists•linuxfoundation.org
> >>>>>>>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>> _______________________________________________
> >>>>>> bitcoin-dev mailing list
> >>>>>> bitcoin-dev@lists•linuxfoundation.org
> >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev@lists•linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > Links:
> > ------
> > [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
>
[-- Attachment #2: Type: text/html, Size: 49635 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-07 3:20 ` Billy Tetrud
@ 2021-07-17 15:50 ` raymo
2021-07-17 18:54 ` Tao Effect
2021-08-08 9:11 ` raymo
0 siblings, 2 replies; 41+ messages in thread
From: raymo @ 2021-07-17 15:50 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
After introducing Sabu protocol as a solution for Bitcoin scaling
(https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180),
I shared this idea with Bitcoin developers through the bitcoin-dev
mailing list.
I got some constructive feedbacks and critiques leading me to add this
part to the proposal which I was skipped due to brevity of proposal
introduction.
Here I will investigate on more real live scenarios, general usages and
corner cases, and the consequences of some attacks or buggy
implementation of protocol, as well as different actors (malicious,
irrational, profit seeker, griefer, stupid, reckless, incompetent, etc.)
activity effects.
In proposal introduction (previous post), I did not talk about Lightning
deliberately, although it seems that this solution is an alternative to
Lightning.
Most of readers misunderstood Sabu and asking what differs it from
Lightning?
Indeed, Sabu has nothing with Lightning. It has totally different
design, network architecture, security model and implementation. The
only thing in common with Lightning is both are intended to cover micro
payments.
The good thing about Bitcoin is that it does not require any kind of
permission. Consequently, related products do not need to ask permission
too. We are in a permission-less free market. I think Sabu will work
perfectly and if a group of users think like me, we are done. Sabu will
work parallel the other scaling solutions without need to drive them
out.
However, I have made a comparison between Sabu, on-chain and Lightning
transactions to get a clearer understanding of the advantages and
disadvantages of Sabu and answer to “why we should implement and use
Sabu in our day-to-day deals”.
Most probably this paper is not comprehensive document, therefore this
article will be updated.
You will find the complete post here:
https://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e
Raymo
On 2021-07-07 03:20, Billy Tetrud wrote:
>> As far as I know the “claw back” mechanism doesn’t exist in
> Bitcoin
> system, and probably most Bitcoiners won’t be agree on it.
>
> It certainly doesn't. And it would definitely be a hard sell.
>
>> It looks the miners still can abuse Sabu, but as I told before the
> mineror better say the mining pool must be issuer .. or must be
> creditor .. or collaborate one of them in a
> conspiracy.
>
> Yes. But it certainly incentivizes miners to become creditors and scam
> people. Even if a small miner who mines one block a year does this,
> they can mine all Guarantee Transactions in their possession. Larger
> miners that mine one block every few days can scam that much more
> often. Even with $5 credits, that could be an extra $9000 gained in a
> block. That's pretty substantial when fees are totaling around $45,000
> per block.
>
>> would be resolved by a slightly upgrade in Bitcoin protocol by
> applying the BIPxxx “for flagging/unflagging promised UTXOs”
>
> As others have mentioned tho, doing something like that would be at
> very least quite complex, and at worst impossible to do securely. The
> whole reason why bitcoin's blockchain exists in the first place is to
> be a single source of truth for transactions. The mempool is not a
> source of truth for consensus. The Sabu network could not be a source
> of truth either for consensus, without some serious innovations (that
> may not be possible). It isn't as simple as you seem to be thinking.
>
>> The new transaction will use same 40,000 UTXO as input and the
> outputs will be 6,500 Sat for creditor (he pays 2,500 Sat for
> transaction fee) 4,500 Sat for creditor 2
>
> This is the part I was unable to find/understand quickly enough in the
> original write up. So for creditor 1 to pay creditor 2, a new main
> transaction and guarantee transaction are created that credit the
> appropriate people, right? FYI, the MT and GT acronyms make it harder
> for me to read/understand, so I'm preferring to write them out. But
> that helps. Let me write this out in a different (more compact) way:
>
> 1. Creditor A $5 -> Issuer
>
> 2. Issuer creates and shares transactions:
>
> Main Transaction (40k sats):
> * Issuer: 19k sats
> * Creditor A: 11k sats
> * Fee: 10k sats (4k from creditor, 6k from issuer)
>
> Guarantee Transaction (40k sats):
> * Issuer: 13,300 sats
> * Creditor A: 1650 sats
> * Fee: 25,050 sats
>
> 3. Creditor A, 6k sats -> Creditor B. Issuer creates and shares
> transactions:
>
> Main Transaction (40k sats):
> * Issuer: 19k sats* Creditor A: 6,500 sats
> * Creditor B: 4,500 sats
>
> * Fee: 10k sats (4k from creditor, 6k from issuer)
>
> Guarantee Transaction (40k sats):
> * Issuer: 13300 sats* Creditor A: 975 sats
> * Creditor B: 675 sats
> * Fee: 25050 sats
>
> Is this right?
>
>> The miner attack is just a failed plan as I explained before
>
> I thought you acknowledged that the miner attack is an issue above.
> No?
>
>>> Sabu has slightly greater risk comparing lightning
>> It is not true,
>
> What I mean is that a violation of trust results in more damaging
> effects with Sabu than with lightning. In lightning, if your channel
> partner cheats, at worst you must simply pay a normal transaction fee.
> With Sabu, if a creditor cheats, you will likely pay an abnormally
> large transaction fee. This is what I mean by "greater risk". Some
> attackers are what's known as griefers - these are people willing to
> spend time and money hurting someone else, even if they don't make a
> profit from it (other than schadenfreude). It seems clear there is a
> greater risk of being griefed in Sabu than in lightning.
>
> Furthermore, while in lightning, if you perform the protocol properly,
> your funds can never be stolen except in very extreme circumstances
> (eg widespread long-running network congestion that prevents
> confirming a revoke transaction). By contrast, Sabu has a significant
> likelihood that a cheating transaction could be mined instead of the
> guarantee transaction. Perhaps the likelihood is approximately 2
> seconds / 10 minutes (0.3% chance), but a 0.3% is clearly larger than
> approximately 0% chance in lightning. Again, this is another part of
> what I mean by "higher risk".
>
> These are both real counterparty risks that you shouldn't simply
> ignore. It may be true that no rational actor will attempt an attack,
> however not all actors are rational. People also make mistakes, write
> buggy software, etc etc. The existence of risk doesn't ruin your idea
> - every protocol has risks. But identifying the specific risks is the
> only way to compare the properties against alternatives (like on chain
> transactions or the lightning network). I think its important to
> acknowledge these risks in your write up.
>
>> I explained before this kind of attacks will not happened never
>
> If people use your protocol, some will inevitably use it wrong. Those
> that use it wrong should be the ones that pay the price for it - but
> it is a downside of the protocol if the counter party of the person
> that makes a mistake (or attempts something malicious) is harmed as a
> result. Again, these kinds of trade offs are ok, but you should not be
> assuming that attacks like this will never happen. They will happen
> sometimes. You must assume that. The question is what is the result
> when an attack is attempted? And how will that affect what kinds of
> actors will attempt an attack (malicious, profit seeking, honest,
> stupid, wreckless, incompetent, other types of actors etc etc)?
>
>> I didn’t find any case Lightning can compete with Sabu.
>
> As I explained above related to risk, there are trade offs. I would
> like to see in your write up a clear list of these trade offs. The
> additional risk (as I explained it above) is one trade off. It sounds
> like there are limits in which a creditor or issuer can safely rely on
> incentives to prevent attacks. Did you specify what those limits are?
> The Lightning network also has limits - eg a lightning node can't
> allow its channel partner to spend 100% of their coins without taking
> on additional risk of attack. How do those limits compare in Sabu? For
> example, an issuer couldn't allow any creditor to spend so much of
> their credited bitcoin that their credit goes below the amount they
> would receive in any past Guarantee Transaction without taking on the
> risk that the creditor would post that guarantee transaction and
> receive coins they shouldn't own anymore. I would love to see a more
> detailed comparison of Sabu to lightning.
>
> If your protocol works out, there are obvious benefits: transactions
> that could be done with no on-chain footprint. However, even if the
> protocol works out, there are trade offs and those trade offs should
> be made very clear. Even if the comparative downsides are small.
>
> ~BT
>
>> Hi Billy
>>> high-level overview of how all the pieces (How Sabu protocol
>> works).
>>> how normal transactions happen in their entirety.
>> Ok, lets re-explain Sabu. In Sabu protocol we have two type of
>> actors.
>> The issuers who own Bitcoin (they own UTXOs on Bitcoin blockchain),
>> and
>> the creditors who will own Bitcoins (the UTXOs on Bitcoin
>> blockchain),
>> if the issuer or the creditor sends the prepared transaction to
>> Bitcoin
>> network. But for know creditors have the transaction in their hand.
>> Before sending this transaction to Bitcoin network it acts (in Sabu
>> protocol and Sabu network) as a liability of issuer.
>> The story always starts from issuer, the person who get money or
>> goods
>> or services from a creditor and in exchange creates and sings a
>> valid
>> Bitcoin transaction by which the issuer spends his UTXO and as a one
>> of
>> the outputs of the transaction, there will be an output for
>> creditor’s
>> address equal to the money issuer already get paid.
>> This transaction is a valid transaction which is signed “only”
>> by
>> issuer. The outputs of transaction are just and exact balance of the
>> parties (issuer and creditor).
>> Lets, imagine the creditor payed 5$ (almost equal to 15,000 Sat) to
>> issuer. Thus, issuer will create and sign a transaction by which he
>> spends 40,000 Sat and the outputs will be
>> 11,000 for creditor (the creditor has to pay 4,000 Sat in favor of
>> transaction fee),
>> 10,000 for Bitcoin-transaction-fee (4,000 by creditor and 6,000 by
>> issuer) and
>> 19,000 change back to issuer account address.
>> It is our Main Transaction (MT) which is a pretty normal and valid
>> transaction.
>> Alongside the MT, issuer creates and signs a Guarantee Transaction
>> (GT).
>> In GT issuer spends same 40,000 Sat UTXO as input, and as outputs
>> the creditor will get 15% of his 11,000 Sat in Main Transaction.
>> Thus
>> the creditor output will be 1,650 Sat and the rest of creditor’s
>> money
>> (11,000 – 1,650 = 9,350 Sat) will be added to transaction fee.
>> In GT also issuer will lose a part of his money. New output for
>> issuer
>> will be 19,000 * 70% = 13,300 and the rest will be added to
>> transaction
>> fee (19,000 – 13,300 = 5,700 Sat)
>> Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =
>> 25,050 Sat
>> Now the creditor has 2 valid transactions (MT and GT) in his hands.
>> He
>> can send either MT or GT or both to Bitcoin Network. But in all
>> cases,
>> he will lose a portion of his money in favor of transaction fee
>> (miner’s
>> income). So, rationally he will never send transactions to Bitcoin
>> network unless he wants consciously hurt himself.
>> The creditor always prefers to spend his credit inside the Sabu
>> protocol. It is “how normal transactions happen in their
>> entirety.”
>> Creditor has equal to 15,000 Sat credit. Say he wants to buy a caffe
>> worth 6,000 Sat. He has to ask the issuer to nullify previous MT and
>> GT,
>> and create and sign new transaction and cut 6,000 Sat from his
>> credit
>> and transfer it to a new creditor (say C2).
>> The new transaction will use same 40,000 UTXO as input and the
>> outputs
>> will be
>> 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee)
>> 4,500 Sat for creditor 2 (he has to pay 1,500 Sat for transaction
>> fee as
>> well)
>> 10,000 for Bitcoin-transaction-fee (4,000 by two creditors and 6,000
>> by
>> issuer) and
>> 19,000 change back to issuer account address.
>> This is the new MT, and as you can see the C1 and C2 have their new
>> credit in transaction.
>> You can calculate the new GT as well.
>> Note: due to simplicity I just rounded the numbers and skipped the
>> Sabu-transaction-fee
>> I just wrote this long story to explain how creditors just transfer
>> money in between.
>> If we take a snapshot of Sabu network, we will see millions of valid
>> transactions flowing in network and none of the issuers or creditors
>> will send these transactions to Bitcoin network due the transaction
>> fee,
>> while in Bitcoin blockchain nothing is changed! The UTXOs are
>> untouched,
>> and no one can say which UTXO is promised to who.
>> It is a pretty secure off-chain protocol.
>> Although I expected more Bitcoiners to react about Sabu proposal and
>> comment for or against it, so far, I have not seen any serious
>> criticism
>> or real threat about protocol.
>> The miner attack is just a failed plan as I explained before.
>>> Sabu has slightly greater risk comparing lightning
>> It is not true, since creditors can manage they risk, and limit
>> their
>> credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor to
>> accept more liability from issuers or not.
>> The creditor can keep his credit around a fix number. That is, the
>> creditor spends a part of his credit and then again increase its
>> credit.
>> Let imagine you already payed 5$ to a issuer and you got 15,000 Sat
>> credit in your wallet. So, you will spend this 15,000 Sat (buy
>> coffee,
>> ice-cream, etc.) till your wallet run out of Satoshi and again you
>> will
>> pay another 5$ to issuer and get new 15,000 sat credit. Since all of
>> these transactions has near zero cost you are not obliged to charge
>> your
>> wallet 200$ in one shot.
>> It is absolutely low risk deal. In worst case the creditor (you)
>> will
>> lose 5$. And as I explained before this kind of attacks will not
>> happened never. And as you told Sabu provides cheaper and a larger
>> number of transactions.
>>> This would be essentially worse than the lightning network in some
>> ways,
>> Disagree! Please explain the scenario exactly. I didn’t find any
>> case
>> Lightning can compete with Sabu.
>>> ledger of accounts and their balances, along with proof that the
>> entity owns…
>> It is almost what I designed in Sabu. They are doc-watcher servers.
>> They
>> are a set of records of UTXOs and the proper Merkle root hash of
>> related
>> transaction in Sabu network. The intention was stopping issuer from
>> spend and promises same UTXO to different people (that they are not
>> aware of the existence of the other). So, any individual creditor
>> (or
>> their software) could verify that total liabilities (in account
>> balances) are less than the half of the total bitcoins the entity
>> owns.
>> And if something doesn't match up, they won’t yell, instead they
>> refuse
>> the deal in first place, or send the GT to Bitcoin network and hurt
>> the
>> cheater issuer by slashing his money. it is “Tit-for-tat”.
>>> I think it likely has critical security holes. Perhaps you can fix
>> them!
>> There is no critical security hole. Please refer it by facts,
>> numbers
>> and proves.
>> I think I already fixed all critics.
>>
>> Billy! I am actively working on this proposal and if no one cannot
>> show
>> a real problem or security issue in the project, I will start
>> implementing it.
>> Just imagine people regularly using Sabu protocol and send/receive
>> Bitcoin (Satoshi) in billions of small amount transactions every
>> day.
>> This protocol will outspread Bitcoin and will attract a new crowd of
>> penny investors to Bitcoin. The people who can afford 20$ or less
>> monthly to invest on Bitcoin.
>> Sabu brings Bitcoin to a whole new life.
>> It will be the true scalable and mass adaption, and I do not know
>> how to
>> attract more real Bitcoin fans to this proposal!
>> Guys! Here is the Bitcoin renascence.
>> Maybe you can help it.
>> Regards
>> Raymo
>
> On Sat, Jul 3, 2021 at 1:02 AM <raymo@riseup•net> wrote:
>
>> Hi Billy,
>>
>>> What if it was possible for the creditor to claw back the funds
>> As far as I know the “claw back” mechanism doesn’t exist in
>> Bitcoin
>> system, and probably most Bitcoiners won’t be agree on it.
>> Even if we want to add claw back to Bitcoin in general, and Sabu in
>> particular, it would add too complexities and uncertainty to
>> Bitcoin.
>> So, it would be better to not touch that part, instead focusing on
>> reduce the cheating risk by putting some penalty for both issuers,
>> creditors and miners.
>> We already have the penalties for both issuers and creditors.
>> It looks the miners still can abuse Sabu, but as I told before the
>> miner
>> or better say the mining pool must be issuer (to be able to sign the
>> promised UTXO in cheating way) or must be creditor (in order to have
>> a
>> copy of GT and not lose his money in favor of a stranger miner.
>> Remember
>> the fact that creditor will lose 70% of their money in favor of
>> Bitcoin
>> transaction fee in a typical GT) or collaborate one of them in a
>> conspiracy. Otherwise, there will be no economic benefit in this
>> attack.
>>
>> All these 3 cases of the attacks, theoretically could be happened,
>> but
>> the risk to reward ratio is enough high to hinder potential
>> malevolent
>> from a practical act.
>> Even this very small risk of miner attacks (which don’t care the
>> attack
>> costs, since he is not interested in economic benefit, but he wants
>> to
>> ruin Sabu), would be resolved by a slightly upgrade in Bitcoin
>> protocol
>> by applying the BIPxxx “for flagging/unflagging promised UTXOs”.
>>
>> I am not in rush to apply this upgrade on Bitcoin protocol, instead
>> I am
>> actively working in order to realize the Sabu protocol and Gazin
>> wallet.
>> Later the Sabu community will carry the BIPxxx.
>>
>> Best
>>
>> On 2021-07-02 17:57, Billy Tetrud wrote:
>>> Thanks for the details Raymo. A thought occurred to me. Given the
>> fact
>>> that miners can abuse this system without penalty, it would be
>> useful
>>> to be able to fix this. What if it was possible for the creditor
>> to
>>> claw back the funds even if the cheating transaction was mined
>> instead
>>> of the guarantee transaction? Let's say there was a way to sign a
>>> transaction that gives the receiver of that transaction the
>> ability to
>>> override any other transaction that uses the UTXO? If this were
>>> possible, the issuer could give the creditor this kind of
>> transaction
>>> as the guarantee transaction, and in the case a cheat was done,
>> the
>>> creditor could still use the GT to reallocate that UTXO to
>> themselves.
>>>
>>> Now there are issues with this. First of all, it could give anyone
>> the
>>> ability to double spend. So it would be prudent to limit this in
>> some
>>> way. The revocation probably should only be valid for up to 6
>> blocks,
>>> such that if the transaction has 6 confirmations, it can no longer
>> be
>>> reallocated (thus preserving the 6 block finality rule). It could
>> also
>>> be required that the UTXO be marked as opting into this behavior
>> (so
>>> receivers would know about the possibility it could get revoked).
>> This
>>> second requirement would require Sabu issuers to make an on-chain
>>> transaction to set themselves up as an issuer.
>>>
>>> Another issue is that this would make it possible for transactions
>> to
>>> expire. Any claw-back transaction would expire 6 blocks after the
>>> initial transaction happened. This has been generally avoided in
>>> bitcoin, but I think the relevant issues are solvable. You can
>> find
>>> additional discussion of that in this thread [1].
>>>
>>> I would imagine this kind of ability would be pretty
>> controversial,
>>> but since it can close out the possibility for miners to escape
>>> punishment, it could make this protocol viable.
>>>
>>> On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup•net> wrote:
>>>
>>>> Hi Erik
>>>>
>>>> Please correct me if I misunderstood.
>>>>
>>>>> email is fully compromised.
>>>>
>>>> What I got is:
>>>> Email is not good because the sender and receiver are
>> compromised.
>>>> Email is not good because the message content is revealed.
>>>> I can claim same argue about any other client/server model. Since
>>>> the
>>>> server (website) service provider will ask some sort of KYC. And
>>>> even if
>>>> the server uses end-to-end encryption, the provider company still
>>>> can
>>>> read the packets content.
>>>> In my model the passive listener only can discover who is
>>>> communicate to
>>>> whom and make a graph of connections. Although it is a threat for
>>>> privacy but the server/client model has this flaw inherently,
>> since
>>>> provider already knew everything about everyone. In my model at
>>>> least
>>>> users can make some fake connections and send some fake emails in
>>>> order
>>>> to inject noise to communications.
>>>> Please note the fact that entire communication between mobile
>>>> wallets
>>>> (via emails) are asymmetric PGP encrypted. The PGP keys are
>>>> controlled
>>>> by end users unlike ALL pretending secure messengers (e.g
>> whatsApp,
>>>> signal, zoom,…).
>>>> If you are worried about the way of exchanging PGP public key,
>> you
>>>> are
>>>> right. The most secure way is in-person PGP key exchanging.
>>>> After that for payments the wallets communicate in pgp encrypted
>>>> messages and they can transfer Bitcoin address through an PGP
>>>> encrypted
>>>> cipher, thus no revealing Bitcoin address to public would occur.
>>>> Neither
>>>> the amounts of transactions will be reviled.
>>>> There for it would be a good practice for shops to put their
>> email
>>>> and
>>>> PGP public key on shop website and/or PGP public key servers,
>>>> instead of
>>>> putting Bitcoin address on website or using 3rd parties services
>> to
>>>> hide
>>>> their Bitcoin payment addresses.
>>>>
>>>> If I missed some points about “fully compromised” please
>> write
>>>> it to me.
>>>>
>>>>> public keys / addresses are sent
>>>> As I told before ALL communication in Sabu are PGP encrypted.
>>>>
>>>>> other routing data encrypted with public keys
>>>>> (not sure how data is routed in sabu)
>>>>
>>>> Sabu is not responsible for routing at all. It simply sends
>> emails.
>>>> Indeed the wallets peer-to-peer network in Sabu is pretty
>> straight
>>>> forward. Each mobile wallet has one email address as its handler
>> and
>>>> identifier in mobile-wallets-network. Each mobile can send
>> message
>>>> to
>>>> another mobile by knowing its email address and the PGP public
>> key.
>>>> This information can be prepared in first face-to-face contact of
>>>> mobile
>>>> owners, or later (something like signing the other’s public key
>> in
>>>> web
>>>> of trust) when a creditor wants to spend his money and transfer
>> it
>>>> to
>>>> another creditor. The creditor1 send the signed money transfer
>>>> request
>>>> alongside the email and public key of creditor2 all in a PGP
>>>> encrypted
>>>> message to issuer.
>>>>
>>>>> separate the Sabu protocol from the app... allow others to
>>>> implement
>>>>> desktop version, or other versions that use other routing
>> systems
>>>>
>>>> Indeed, it is my approach too. As I told before users will decide
>>>> between an unstoppable, permission less, self-sovereignty and
>>>> decentralized pure peer-to-peer communication network (with some
>>>> resolvable privacy issues) or some efficient, privacy-mimic
>> central
>>>> limited network.
>>>>
>>>>> you can allow direct-entry of a BIP-word-representation
>>>>> of a public key/address to avoid privacy/central system concerns
>>>> Agree. Actually, I was thinking about an easy mechanism to share
>>>> your
>>>> public key like what you suggested here.
>>>> But what I consider for a “central system concerns” is the
>>>> ability of
>>>> communication without dependency to any company.
>>>> As an example, what can you do if the twitter bans your account?
>>>> Nothing! Your content and entire connections will be lost.
>>>> But if you form your friends list in your mobile (or computer)
>> and
>>>> have
>>>> their PGP public keys and they have yours, and use email as a
>> dual
>>>> purpose tool. First as a handler (the tool for finding and to be
>>>> found
>>>> in internet) and second as a communication tool.
>>>> Thus, no one can stop you, ban you or limit you to send/receive
>>>> transaction to/from anyone.
>>>> What I am trying to say is using email is far better than account
>>>> (username) in a limited central service like twitter, Facebook,
>>>> telegram... or even in future Sabu servers!
>>>> You have your connections under your control in your phone. You
>> can
>>>> easily change your email and use a new email or even a new
>> service
>>>> provider without losing your connections and your control over
>> it.
>>>> You just sign your new email address and send it to your friends
>>>> circle
>>>> and notify them about changes.
>>>> Of course, email is not good for millions of followers but it is
>>>> obviously good for managing your payment network of hundreds of
>>>> people
>>>> (either issuers or creditors).
>>>>
>>>> Best
>>>> Raymo
>>>>
>>>> On 2021-07-01 20:49, Erik Aronesty wrote:
>>>>> your protocol should always assume the email system is fully
>>>>> compromised, and only send public information over email:
>>>>>
>>>>> - public keys / addresses are sent
>>>>> - other routing data encrypted with public keys (not sure how
>> data
>>>> is
>>>>> routed in sabu)
>>>>>
>>>>> your end user should be able to verify public keys / addresses
>>>>>
>>>>> - use QR-codes
>>>>> - phone calls with users reading BIP words out loud
>>>>> - other in-person information exchange
>>>>>
>>>>> separate the Sabu protocol from the app... allow others to
>>>> implement
>>>>> desktop version, or other versions that use other routing
>> systems
>>>>>
>>>>> - you can allow direct-entry of a BIP-word-representation of a
>>>> public
>>>>> key/address to avoid privacy/central system concerns
>>>>>
>>>>> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
>>>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>>
>>>>>> Hi Billy,
>>>>>> Sorry for late reply. Let’s jump in proposal.
>>>>>>
>>>>>>> Some more information about the benefits of this approach vs
>>>> alternatives (mainly lightning)
>>>>>> The most important different is unlike the lightning, in Sabu
>> no
>>>> one
>>>>>> have to open a channel and pay Bitcoin transaction fee,
>>>> subsequently no
>>>>>> one has to close channel and pay another Bitcoin transaction
>> fee.
>>>> It is
>>>>>> the huge improvement since it drops the overhead cost of
>>>> transactions.
>>>>>> So, it will be more convenience to trade under Sabu protocol.
>>>>>> In Sabu none of parties of a transaction are obliged to block
>>>> money in
>>>>>> any kind of smart contract or any other m of n signature
>> accounts
>>>>>> on-chain, so it provides more privacy.
>>>>>> Since Sabu protocol is designed to motivate people to circulate
>>>>>> transactions (AKA debt documents) in Sabu network, if every
>> actor
>>>> act
>>>>>> rationally no one will aware how much money transferred from
>> who
>>>> to
>>>>>> whom.
>>>>>> In case of fraudulent activity by issuer, the creditor will
>> send
>>>>>> Guarantee Transaction (GT) to Bitcoin network in order to
>>>> recapture the
>>>>>> part of his credit. So, in this case the transaction is
>> literally
>>>>>> recorded on bitcoin blockchain.
>>>>>> There is only one another reason to recording transaction on
>>>> Bitcoin
>>>>>> blockchain. Where one creditor eager to pay Bitcoin transaction
>>>> fee in
>>>>>> order to aggregate thousands or even millions different small
>>>> amount
>>>>>> debt-documents in a single transaction on Bitcoin blockchain.
>>>>>> despite these two cases, the rest of transactions all occur in
>>>> the Sabu
>>>>>> network (supposed to be over 99%). Thus, no footprint no
>>>> bottleneck and
>>>>>> no over process.
>>>>>>
>>>>>> Another important power point of Sabu is its pure-peer-to-peer
>>>> network
>>>>>> architecture. In Sabu the mobile wallets communicating to each
>>>> other
>>>>>> directly without any central server. There is no centralization
>>>> at all.
>>>>>> As a result, there will be no routing as well.
>>>>>> Since only issuer and creditors are aware of the content of
>>>> transaction
>>>>>> (who pay how much to whom) it is a huge privacy improvement,
>>>> which
>>>>>> doesn’t exist in other layer 2 solutions.
>>>>>>
>>>>>> About the usability of Sabu, although the protocol based on the
>>>>>> collaborating 2 different peer-to-peer network and 3 classic
>>>>>> server/client networks, but the end user (mobile wallet user)
>>>> doesn’t
>>>>>> see any of these complexities.
>>>>>> The end user simply installs the mobile/desktop wallet and add
>>>> her/his
>>>>>> friends to his phonebook by adding their email address or
>>>> scanning their
>>>>>> email (and/or PGP public key). After that s/he can immediately
>>>> start to
>>>>>> send/receive Bitcoin through Sabu network. Entire
>> communications
>>>> between
>>>>>> wallets are PGP encrypted.
>>>>>> Another good point in Sabu design is, the 12 seed words are
>> using
>>>> for
>>>>>> both Bitcoin wallet private key and the PGP private key. So, it
>>>> is the
>>>>>> key of user wealth and its identity as well. For more details,
>>>> please
>>>>>> read my previous answer to Alex Schoof.
>>>>>> The issuer, by using his UTXOs and selling them to creditors
>> earn
>>>> money.
>>>>>> the issuer creates the debt document (transaction) by which
>>>> promises to
>>>>>> creditor an amount of satoshi. These debt documents are valid
>>>> Bitcoin
>>>>>> transaction. The only difference is these transactions are
>>>> intended to
>>>>>> circulate in Sabu protocol instead of sending to Bitcoin
>>>> blockchain.
>>>>>> Each transaction is a small money transfer. 40,000 Satoshi as
>>>> input and
>>>>>> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as
>>>> Bitcoin
>>>>>> transaction fee.
>>>>>> The creditors will use these received transactions as money and
>>>> will pay
>>>>>> it in exchange of goods or services. For each transaction the
>>>> creditor
>>>>>> pays 10 Satoshi as Sabu-transaction-fee to issuer.
>>>>>> Sabu is not custodial service and the UXTOs are always under
>>>> issuer
>>>>>> control, unless issuer or creditor send the signed transaction
>> to
>>>>>> Bitcoin network. When the transaction was recorded in Bitcoin
>>>>>> blockchain, the creditor can spend proper UTXO in Bitcoin
>>>> network.
>>>>>> Imagine million people use their UTXOs in Sabu, they are issuer
>>>> and
>>>>>> issue/update/cancel million transactions per second. All they
>>>> need is a
>>>>>> mobile wallet. On the other hand, every one by knowing an
>> issuer
>>>> can buy
>>>>>> some Satoshi (whit absolutely no KYC), even 1 Dollar or less,
>> and
>>>> spend
>>>>>> it, this time Alice really can buy caffe by Bitcoin ;)
>>>>>> The Bar can install the mobile wallet and every day receives
>>>> thousands
>>>>>> of debt documents (transactions), each worth maximum 20,000
>>>> Satoshi in
>>>>>> exchange of coffee. And every evening aggregates those small
>>>>>> transactions to one single transaction and send it to Bitcoin
>>>> network.
>>>>>>
>>>>>>
>>>>>> The security model of Sabu is pretty straight forward.
>>>>>> Issuer is the owner of UTXO(s) which will be used in
>>>> transactions. The
>>>>>> issuer is and will the only person who creates transactions and
>>>> sign
>>>>>> them. The transactions are valid transaction which either
>> issuer
>>>> or
>>>>>> creditor can send them to Bitcoin network, but they will never
>>>> send
>>>>>> these transactions to Bitcoin network, because of the high
>>>> Bitcoin
>>>>>> transaction fee for each single transaction.
>>>>>> Since issuer is the only one who can sign transaction (spend
>>>> UTXOs),
>>>>>> there is a risk of issuer cheating. And no one can stop issuer
>>>> from
>>>>>> cheating, because these are his UTXOs and he has the proper
>>>> private
>>>>>> keys.
>>>>>> The Sabu solution is Guarantee transaction. It is a valid
>>>> transaction
>>>>>> that issuer has to sign it alongside the Main transaction. In
>> GT
>>>> both
>>>>>> issuer and creditor cut a part of their output in favor of
>>>> Bitcoin
>>>>>> transaction fee.
>>>>>> We suppose miners always seeking for more profit, thus in a
>> case
>>>> there
>>>>>> are 2 or more transaction are spending same UTXO as input,
>> miner
>>>> will
>>>>>> choose transaction with highest feeRate. There is no
>> economically
>>>>>> benefit for issuer to cheat creditors and pay less transaction
>>>> fee
>>>>>> simultaneously. So rationally the issuer won’t cheat
>> creditor.
>>>>>> It was the simplest explanation of Sabu security model.
>>>>>>
>>>>>>> I agree with others that using email is probably not
>>>> appropriate for a protocol like this. I would highly recommend
>>>> making your protocol transport-agnostic, allowing users of your
>>>> protocol to use any transport they want.
>>>>>> Indeed, the protocol is transparent-agnostic, if I insist of
>>>> email as a
>>>>>> user identifier and communicating tool is because of the idea
>> of
>>>>>> reforming part of internet architecture and make it more
>>>> decentralized.
>>>>>> The wallet users can choose classic architecture. In this case
>>>> mobile
>>>>>> wallets will connect to a central server and communicate
>> through
>>>> that
>>>>>> server (pretty much like all existed mobile wallets). While
>> some
>>>> users
>>>>>> decide to use a pure peer-to-peer communication. I knew email
>> has
>>>> some
>>>>>> privacy issues but as always it is a tradeoff. Users can decide
>>>> between
>>>>>> an unstoppable, permission less, self-sovereignty and
>>>> decentralized pure
>>>>>> peer-to-peer communication network (with some resolvable
>> privacy
>>>> issues)
>>>>>> or some efficient central limited network.
>>>>>> Let me know the critics about email. Hopefully this would lead
>> us
>>>> to
>>>>>> improve email instead of letting it die. I strongly suggest
>> email
>>>>>> because it is the ONLY neutral, free “nonproprietary” and
>>>> open
>>>>>> protocol/technology for communication in the world that its
>>>>>> infrastructure is well-established and is accessible all over
>> the
>>>> glob.
>>>>>>
>>>>>> I tried to explain it more, hope was useful. By the way the
>>>> complete
>>>>>> explanation is here
>>>>>>
>>>>
>>>
>>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Raymo
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2021-06-22 18:20, Billy Tetrud wrote:
>>>>>>> I would be interested in seeing some more information about
>> the
>>>>>>> benefits of this approach vs alternatives up front in this
>>>> write up.
>>>>>>> Eg how does the security, cost, usability, and privacy compare
>>>> to the
>>>>>>> lightning network, which would be the most likely competitor
>> to
>>>> this
>>>>>>> idea. It seems clear that there is more counterparty risk
>> here,
>>>> so it
>>>>>>> would probably also be very helpful to compare against
>>>> traditional
>>>>>>> custodial solutions as well. If you have specific claims on
>> how
>>>> this
>>>>>>> system is better than eg lightning in certain contexts, it
>>>> would be
>>>>>>> far easier to evaluate the protocol against those claims, and
>>>> would
>>>>>>> also be a lot easier for readers to be motivated to read the
>>>> whole
>>>>>>> protocol and do a more full analysis.
>>>>>>>
>>>>>>> I agree with others that using email is probably not
>>>> appropriate for a
>>>>>>> protocol like this. I would highly recommend making your
>>>> protocol
>>>>>>> transport-agnostic, allowing users of your protocol to use any
>>>>>>> transport they want.
>>>>>>>
>>>>>>> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
>>>>>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>>>
>>>>>>>> I think you're making a number of assumptions about mining
>>>> that are
>>>>>>>> not accurate.
>>>>>>>>
>>>>>>>>> First of all, how much chance in finding next block the
>>>> corrupted
>>>>>>>> miners have? One percent of all Bitcoin hash powers? Or
>>>> maximum 5
>>>>>>>> percent or 10? The cheaters must come up in dividing that 1.2
>>>>>>>> Bitcoin between. After all the risk/reward must fit them.
>> They
>>>> can
>>>>>>>> not be a big mining pool since there is no benefit, so they
>>>> will be
>>>>>>>> small miners with low hash rate. If they solve the puzzle and
>>>>>>>> broadcast the block, no one in the entire Bitcoin network has
>>>> block
>>>>>>>> transactions or seen it before in their mempool!
>>>>>>>>
>>>>>>>> You're making the assumption that miners won't build on top
>> of
>>>> a
>>>>>>>> block
>>>>>>>> with transactions they have not seen before or transactions
>>>> that may
>>>>>>>> contain double spends of unconfirmed inputs, this is not how
>>>> mining
>>>>>>>> works, as long as the block passes the consensus rules
>>>> effectively
>>>>>>>> all
>>>>>>>> miners will mine on top of it by default, this behavior is
>>>>>>>> fundamental
>>>>>>>> to how mining currently works and is fairly deeply baked into
>>>> the
>>>>>>>> current mining infrastructure.
>>>>>>>>
>>>>>>>>> Will they accept this block? In theory it is possible and
>>>> have
>>>>>>>> 0.01 percent chance but we can eliminate this small
>>>> possibilities by
>>>>>>>> a simple BIP for miners.
>>>>>>>>
>>>>>>>> What would this BIP look like? I don't see how this could
>> work
>>>> in a
>>>>>>>> decentralized way as you would need another way of reaching
>>>>>>>> consensus
>>>>>>>> on what defines a valid block. Right now the chance is nearly
>>>> 100
>>>>>>>> percent that a miner will mine on top of the latest valid
>>>> block,
>>>>>>>> many
>>>>>>>> pools(most last I checked) will even mine on the next block
>>>> before
>>>>>>>> they validate the latest block fully(ie validationless
>> mining)
>>>> to
>>>>>>>> reduce their orphan rates.
>>>>>>>>
>>>>>>>>> We suppose the miners always control transactions with
>>>>>>>> doc-watchers and avoid accepting transaction with same UTXO
>>>> but
>>>>>>>> different output.
>>>>>>>>
>>>>>>>> Miners have different mempool policy/rules for what
>>>> transactions
>>>>>>>> they
>>>>>>>> themselves mine but all miners must mine on the most work
>>>> chain of
>>>>>>>> valid blocks otherwise they risk their own blocks being
>>>> orphaned,
>>>>>>>> any
>>>>>>>> miner that does not do this is effectively guaranteed to have
>>>> their
>>>>>>>> block orphaned right now.
>>>>>>>>
>>>>>>>>> Because of high Bitcoin transaction fee, this guarantee
>>>>>>>> transaction will take place in next block, even if other
>>>> transaction
>>>>>>>> which are using the same UTXO as input existed in mempool.
>>>>>>>>
>>>>>>>> When a new transaction is broadcast miners do not immediately
>>>> start
>>>>>>>> mining on a block template that includes that transaction,
>> the
>>>>>>>> template won't even be generated immediately when it enters a
>>>> miners
>>>>>>>> mempool in practice, for bandwidth/network efficiency reasons
>>>> mining
>>>>>>>> pools batch update the stratum templates/jobs they mine
>>>> against so
>>>>>>>> there can be significant latency between the time a
>>>> transaction is
>>>>>>>> actually broadcast and hits the miners mempool and the time
>>>> the
>>>>>>>> miners
>>>>>>>> actually switch to mining on top it, these batched updates
>> are
>>>>>>>> essentially like point in time snapshots of the mempool and
>>>>>>>> typically
>>>>>>>> remain valid(as in the pool will accept shares submitted
>>>> against
>>>>>>>> that
>>>>>>>> job as valid) until the bitcoin network finds the next block.
>>>> I
>>>>>>>> don't
>>>>>>>> think these batch updates are done more often than every 30
>>>> seconds
>>>>>>>> typically, while often it is on the order of multiple minutes
>>>>>>>> depending on the pool.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> James
>>>>>>>>
>>>>>>>> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
>>>>>>>> <bitcoin-dev@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@lists•linuxfoundation.org
>>>>>>>>>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>> _______________________________________________
>>>>>>>> bitcoin-dev mailing list
>>>>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>>>>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-17 15:50 ` raymo
@ 2021-07-17 18:54 ` Tao Effect
2021-08-08 9:11 ` raymo
1 sibling, 0 replies; 41+ messages in thread
From: Tao Effect @ 2021-07-17 18:54 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
Hi Raymo,
I personally am excited about what you’re working on, and wish you the best of luck with it!
Cheers,
Greg
> On Jul 17, 2021, at 8:50 AM, raymo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> After introducing Sabu protocol as a solution for Bitcoin scaling
> (https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180),
> I shared this idea with Bitcoin developers through the bitcoin-dev
> mailing list.
> I got some constructive feedbacks and critiques leading me to add this
> part to the proposal which I was skipped due to brevity of proposal
> introduction.
> [..]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-07-17 15:50 ` raymo
2021-07-17 18:54 ` Tao Effect
@ 2021-08-08 9:11 ` raymo
2021-08-09 0:03 ` s7r
1 sibling, 1 reply; 41+ messages in thread
From: raymo @ 2021-08-08 9:11 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Fine tuning Sabu in order to minimize the protocol risks
After representing Sabu protocol
here
(https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180)
and answer some comments and critics here
(https://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e),
I dedicated some days to tuning the Sabu transaction criteria in order
to reduce the risks either for issuers or creditors. After that fine
tuning, most of risks were decreased dramatically. In this post I’ll
represent these details. For whom may forget about how Sabu protocol
work, the core points are repeated for concept recall.
Why should we use Sabu protocol?
The main goal of Sabu is “boosting Bitcoin C2C circulation” by
distributing it between far more people. The protocol incentivizes the
small Bitcoin owners (people who has a tenth of Bitcoin or less) to sell
few Satoshi (4 or 5 dollar or so) in person with no KYC due to Bitcoin
ethos and earn small transaction fees for each transaction. This
movement will end up to 10x or more bigger Bitcoin users, which
definitely improves Bitcoin’s community and its proper ecosystem.
How Bitcoin transaction work?
Owning Bitcoin, means having some UTXO (recorded in Bitcoin blockchain)
under your control. That is, you can sign that UTXO to prove you are the
legitimate owner of that money. Thus, if you want to spend your
Bitcoins, you create a transaction by which sign your under-controlled
UTXO(s) and represent your desire to transfer this ownership to the
other person. This transaction is a document that issued by you and
provides a legitimate order for this money transfer. In order to execute
this money transfer, you need to broadcast your signed document to
Bitcoin network aimed to record it in Bitcoin blockchain, otherwise, no
money transfer has taken place. After recording this transaction in
Bitcoin blockchain, the transfer is settled and "everyone" will be aware
of the new owner(s) of that particular spent coins.
How Sabu protocol work?
You -as a UTXO owner- are an "issuer", and always can issue a document
(AKA transaction) by which you represent your will to transfer some of
your UTXOs to others. Thus, Sabu is a non-custodial protocol. As long as
this debt document is not registered in the Bitcoin blockchain, it is
nothing more than a liability, i.e., you owe some Bitcoins to someone
else. That guy naming her/him "creditor" payed money to you or provided
goods or services for you, in exchange of this debt-document. Thus s/he
has a copy of this transaction in her/his wallet. The issuer or creditor
always can send this transaction to Bitcoin blockchain network aimed to
record this money transformation in Bitcoin blockchain, or keep this
transaction in wallet. But due to the high transaction fee on the
Bitcoin blockchain and the insignificance of the amount transferred (a
few Dollars), they will not send the document to the Bitcoin network,
instead prefers to use this document as a payment method and exchange
these documents in Sabu protocol and in an off-chain manner.
When the creditor wants to spend his money, his wallet will send a
request to the issuer’s wallet and ask it to transfer the issuer’s
liability to another creditor. The issuer prepares a new transaction in
which issuer owes the new creditor(s), and delivers this new transaction
to both old and new creditors.
The issuers earn small Sabu-transaction-fee per each money transfer (one
or two Sat per transaction). Millions of issuers and creditors are
exchanging these documents (transactions) in a peer-to-peer network
continually, with no central authority. There is no blockchain nor
public ledger.
After each dealing, the issuer cancels the old transaction and creates a
new document, and updates the creditor balances. These documents will be
in circulation between issuers and creditors in the Sabu network forever
meanwhile less than one percent of these transactions will be recorded
on the Bitcoin blockchain.
Either issuers or creditors in order to use Sabu protocol need to
install Sabu mobile wallet (called Gazin) and start to deal. That is all
they need. No technical skill or extra cost needed.
How Sabu prevents frauds?
The main mechanism of the system against fraud is the un-profitability
of fraud in terms of economic benefits. In other words, all of malicious
activities will end up in losing money of attacker.
In short, the Sabu anti-fraud system works like that. The issuer always
creates and signs a transaction pair. The Main Transaction which
represents the real amount of outputs. And the Guarantee Transaction
which pays relatively higher Bitcoin-transaction-fee. This fee increment
is obtained by cutting from the issuer and creditor outputs in Main
Transaction.
Check out this simple transaction to learn more about how the system
works.
Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
she can spend it by create a transaction and sign it and broadcast it to
Bitcoin network.
Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
Satoshi from Alice in exchange.
Alice gets this 5$ and prepare a Main transaction that represents this
liability of Alice to Bob.
Main Transaction (20,000 Sat input):
* Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
has to pay 3,000 as BTC fee)
* Alice (issuer): 6,000 Sat
* BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
This is a valid transaction and both Bob and/or Alice can send it to
Bitcoin network, but none of them are interested in doing so. Because
they will lose 5,000 Satoshi of their own money as Bitcoin transaction
fee.
Alongside this transaction Alice (the issuer) has to create the
Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
not consider the deal completed. The Guarantee Transaction is another
valid Bitcoin transaction. It is created based on Main Transaction and
will cut a part of Bob and Alice money in favor of transaction fee.
Guarantee Transaction (20,000 Sat input):
* Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
* Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
* BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from
Bob) + 3,480 (from Al-ice) = 15,739 Sat
The Guarantee Transaction applies when the issuer does not live up to
its promise and intends to spend the promised UTXO(s) in a way other
than that agreed upon. We already knew the fact that Sabu is not a
custodial solution, neither a M of N signature schema. As a result, the
UTXO owner always can spend the already promised UTXO(s) in Sabu
protocol or out of Sabu on Bitcoin blockchain, Contrary to what was
promised.
When the Alice (issuer) breaks such a promise and sends the fraudulent
transaction to the Bitcoin network, Bob's wallet realizes that she
(issuer) is spending the promised UTXO(s) and it sends the Guarantee
Transaction(s) to the network as a last resort. The miners will face two
(or more) transactions which are spending same UTXO(s), but one of them
is paying notably higher Bitcoin transaction fee, thus they chose the
highest fee payer transaction, which is the Guarantee Transaction. The
miner will put the Guarantee Transaction in next block and reject the
rest double-spend transactions. Certainly, poor Bob cannot recoup all
his Satoshis. But he can retrieve a portion of his money and forces
Alice to lose some of her money as well. tit for tat!
Because of this mechanism, the issuer will try to not cheat on creditor.
By the way there are some attacks that have very small chance to succeed
but the risk to reward ratio for these scenarios are too high to be
considered as a real possible attack threat. I will review them a little
later in this post.
What are the advantages of Sabu over Lightning?
There are four benefits to using Sabu.
Cost: In Sabu unlike Lightning, the transaction parties do not need to
open a channel and consequently they do not need to close it. Therefore,
they do not need to pay Bitcoin transaction fees two times. The
transaction parties will pay small Sabu-transaction-fee per each
transaction to the issuer because of creating and signing new
transaction. Every Sabu user can be an issuer (something like Lightning
node) and earn Bitcoin because of issuing credit liability document
(pretty much like banks).
Ease of use: All a user needs to use protocol is install wallet -called
Gazin- on mobile or desktop by one click. The user can be an issuer and
issue transactions or be a creditor and buys Bitcoin or both
simultaneously. Users can then transfer their money to each other in
Sabu network. Every Sabu user can be a creditor and buy some Satoshi
from issuer and spend it in small shopping. It seems that Bitcoiners can
finally buy coffee with Bitcoin without worrying about transaction fee
or system scalability or even recording transaction forever on Bitcoin
blockchain.
Privacy: Since the communication between nodes is PGP encrypted, and no
transaction will go to record on Bitcoin blockchain, the Sabu protocol
provides a strong privacy for transaction parties. Except sender and
receiver, no one will know how much Bitcoin between who was transferred.
Billions of micro transfers will be scattered between thousands of nodes
without no central control point and no transaction history recording
and absolutely no KYC.
Scalability: Since the Sabu has no routing overhead and peers use the
direct communication it will be more scalable than Lightning.
New criteria:
- Each transaction input must be 20,000 Satoshi or more.
- Maximum liability in a single transaction would be 15,000 Satoshi. 14k
for creditor whose credit is more than 1k, so he is eligible to have
both MT & GT in his wallet, and 1k for the creditor without the right of
having MT & GT due to his small amount of credit.
- The maximum transaction fee (for Bitcoin blockchain) for Main
Transaction is 5,000 Satoshi. For transaction with liability less than
4,000 Satoshi this fee would be less than 5,000 Satoshi relatively.
- In Guarantee Transaction the issuer loses 1% to 68% of his output in
favor of Bitcoin transaction fee depends to the liability amount. More
liability more loss.
- In Guarantee Transaction the creditor loses 100% to 78% of his output
in favor of Bitcoin transaction fee in reverse of the credit amount.
More credit less loss.
- The transaction fee (for Bitcoin blockchain) for Guarantee Transaction
would be transaction fee of Main Transaction plus 100% to 78% of
creditor’s output plus 1% to 68% of issuer’s output.
- The issuer has to issue both Main Transaction and Guarantee
transaction and deliver them to creditor.
Both issuer and creditor (sender and receiver) control these criteria
before confirm the deal.
Fraudulent activities risk:
The griefers, - people who willing to spend time and money hurting
someone else, even if they don't make a profit from it (other than
schadenfreude). - still can hurt himself and the other party
simultaneously, but the damage amount is reduced dramatically.
The lowest amount that a griefer as a creditor can lose is 1,000 Satoshi
to hurt the issuer 685 Satoshi (loss ratio 1.45), and the highest amount
is losing 11,506 Satoshi to hurt issuer 4,720 Satoshi (loss ratio 2.43).
In any case, a griefer still has trouble finding big number of victims,
since the protocol is not centralized and the user’s information is
scattered among thousands of different nodes.
How can prevent the issuer from spending UTXO in a cheating way?
There are two possible scenarios for fraudulent issuer. First is paying
high Bitcoin transaction fee, even higher than Guarantee Transaction
fee, with the intention of placing the transaction desired by the issuer
in the next block. Even Guarantee Transaction will cause the issuer to
waive part of his output in favor of Bitcoin transaction fee. Its loss
is between 685 to 5,190 Satoshi. Therefore, carrying out this attack
will not be economically viable.
The second scenario is double spending the promised UTXO, hopping in a
race condition, the cheating transaction win the Guarantee Transaction.
The likelihood of success for this scenario is approximately 2 seconds /
10 minutes (0.3% chance). In other word, the issuer has 0.3% chance to
win 10,000 Satoshi (15,000 Max liability in a transaction – 5,000
minimum transaction fee), and relatively he has 99.7% chance to lose
4,720 Satoshi. The risk to reward ratio is too high to consider this
scenario as a practical attack at all.
What if issuer is miner as well?
What a wicked issuer can earn from a block full of fraudulent
transactions or a real big batch transaction would be in maximum
spending 10,000 promised UTXO as inputs. The issuer already got paid
equal to 10,000 * 15,000 Satoshi from deceived creditors in fiat money
or goods or services. He is a miner as well so the transaction fee is
not the case, thus we can say all the 1.5 Bitcoin is the issuer/miner
benefit. But a normal honest block usually makes same or more profit for
its miner! So, what is the benefit of cheating creditors? The
issuer/miner has to mine solely and take the risk of wasting energy for
almost nothing advanced a normal honest participating in network!
In other word, due to the small amount of inputs and outputs, spending
these Satoshis on any type of Bitcoin transaction is not cost effective
in most cases.
What if creditor is miner as well?
The wicked creditor in every case will lose part of his money, since he
can only put Main transaction or Guarantee Transaction in next block. In
first case he paid unnecessary Bitcoin transaction fee. In second case
he paid even more unnecessary Bitcoin transaction fee.
Conclusion:
Till here, after tuning the transaction parameters and the criteria of a
successful deal, seems most of the risks of Sabu protocol have been
addressed.
I intentionally didn’t talk about BIPxxx “mark/unmark promised UTXOs”,
because the Sabu protocol will work enough good without touching current
Bitcoin core protocol. In future, after implementing BIPxxx, the Sabu
protocol can remove some limitations and improve its features and
functionalities.
What is the next step?
The next step would be putting protocol in practice and developing a
Minimum Viable Product (MVP). I am a developer and I think -for now- the
best technology and stack to develop the protocol and the proper mobile
wallet would be “react native”. The protocol and the software will be
open source and under GPL v3.0. Let me know if you have alternate idea.
At the moment I cannot work full-time on this project and I need some
help,
But I am gradually working on this project and looking forward to hear
from Bitcoin real supporters.
Regards
Raymo <raymo@riseup•net> d89a49057b817be0
this post on medium.com
https://raymo-49157.medium.com/fine-tuning-sabu-in-order-to-minimize-the-protocol-risks-95361dc5282b
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-08-08 9:11 ` raymo
@ 2021-08-09 0:03 ` s7r
2021-08-09 16:22 ` raymo
2022-11-02 17:30 ` Erik Aronesty
0 siblings, 2 replies; 41+ messages in thread
From: s7r @ 2021-08-09 0:03 UTC (permalink / raw)
To: raymo, Bitcoin Protocol Discussion
raymo via bitcoin-dev wrote:
TL,DR: you were explained by ZmnSCPxj why this protocol will not work.
The possibility for just one party to sign will not work. I will explain
again why but in much more simpler description.
> Check out this simple transaction to learn more about how the system
> works.
> Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
> she can spend it by create a transaction and sign it and broadcast it to
> Bitcoin network.
> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
> Satoshi from Alice in exchange.
> Alice gets this 5$ and prepare a Main transaction that represents this
> liability of Alice to Bob.
>
> Main Transaction (20,000 Sat input):
> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
> has to pay 3,000 as BTC fee)
> * Alice (issuer): 6,000 Sat
> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
> This is a valid transaction and both Bob and/or Alice can send it to
> Bitcoin network, but none of them are interested in doing so. Because
> they will lose 5,000 Satoshi of their own money as Bitcoin transaction
> fee.
>
> Alongside this transaction Alice (the issuer) has to create the
> Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
> not consider the deal completed. The Guarantee Transaction is another
> valid Bitcoin transaction. It is created based on Main Transaction and
> will cut a part of Bob and Alice money in favor of transaction fee.
>
> Guarantee Transaction (20,000 Sat input):
> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from
> Bob) + 3,480 (from Al-ice) = 15,739 Sat
>
> The Guarantee Transaction applies when the issuer does not live up to
> its promise and intends to spend the promised UTXO(s) in a way other
> than that agreed upon. We already knew the fact that Sabu is not a
> custodial solution, neither a M of N signature schema. As a result, the
> UTXO owner always can spend the already promised UTXO(s) in Sabu
> protocol or out of Sabu on Bitcoin blockchain, Contrary to what was
> promised.
> When the Alice (issuer) breaks such a promise and sends the fraudulent
> transaction to the Bitcoin network, Bob's wallet realizes that she
> (issuer) is spending the promised UTXO(s) and it sends the Guarantee
> Transaction(s) to the network as a last resort. The miners will face two
> (or more) transactions which are spending same UTXO(s), but one of them
> is paying notably higher Bitcoin transaction fee, thus they chose the
> highest fee payer transaction, which is the Guarantee Transaction. The
> miner will put the Guarantee Transaction in next block and reject the
> rest double-spend transactions. Certainly, poor Bob cannot recoup all
> his Satoshis. But he can retrieve a portion of his money and forces
> Alice to lose some of her money as well. tit for tat!
> Because of this mechanism, the issuer will try to not cheat on creditor.
>
> By the way there are some attacks that have very small chance to succeed
> but the risk to reward ratio for these scenarios are too high to be
> considered as a real possible attack threat. I will review them a little
> later in this post.
>
>
You said that the guarantee transaction is created based on Main
Transaction, how do you mean? If it is a child transaction of the Main
Transaction it already doesn't work because Alice needs to broadcast the
*Main Transaction* to the blockchain in order for the Guarantee
transaction to be accepted, and of she does this, Bob doesn't care
because the transaction pays to him already the correct agreed amount.
If you did not mean this, still it won't work, because
Simple:
1. Alice will create transaction #3, or call it Sabu-killing-transaction
(20,000 Sat input):
* Alice (issuer): 15,000 Sat
* BTC Fee: 5,000 Sat
PERIOD.
When Bob tries to broadcast the "guarantee transaction" he will get an
error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much
larger fee in the guarantee transaction will not matter. You have to
assume a miner will violate the Bitcoin protocol and somehow drop
Sabu-killing-transaction from mempool and consider the Guarantee
transaction only. This is very unlikely to happen and you might also
need connection direct with the miners because most full nodes will not
even accept the Guarantee transaction to their mempools in order to
further broadcast it until it reaches the miners.
With the simple attack described above Alice's chance to fraud Bob are,
from my point of view, 99%.
(the only way to replace a transaction is Replace-By-Fee but this
implies the transaction that IS TO BE REPLACED has a certain flag set,
and it is optional).
Given the Sabu-Killing-transaction comes first, Alice will of course
create it without this flag set so even if you add to Sabu the
requirement of RBF enabled to the Guarantee transaction it will not
work, because it's the other way around.
The second question is just for an observation that it has no real
benefits over Lightning even if #1 wasn't true:
2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he
is connected to the internet, otherwise if he loses connection to the
internet or energy supply, Alice attack will succeed entirely with 100%
chances. So this means Bob needs to always be online like forever and ever.
The 3rd one is hypothetical and you don't even have to answer it:
3. How does Bob (first creditor) spend the coins received / how does Bob
become an issuer himself in relation to Dave (another creditor)? What
happens if Alice tries to fraud Bob after Bob spent its Sabu credit to
Dave? Dave has to hold all parent "guarantee transactions" and watch the
network for any potential fraudulent transactions that cancels his credit?
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-08-09 0:03 ` s7r
@ 2021-08-09 16:22 ` raymo
[not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
2022-11-02 17:30 ` Erik Aronesty
1 sibling, 1 reply; 41+ messages in thread
From: raymo @ 2021-08-09 16:22 UTC (permalink / raw)
To: s7r; +Cc: Bitcoin Protocol Discussion
Hi s7r,
I already answered to ZmnSCPxj's comments.
Let’s go to yours.
> If it is a child transaction of the Main Transaction
Sorry for my shortcoming in English, because it caused the
misunderstanding of proposal.
There is not any relation between Main Transaction and Guarantee
transaction. when I said “the Guarantee Transaction is created based on
Main Transaction” I was intended only the numbers. I mean the output
amounts of Guarantee Transaction are calculated relatively based on Main
Transaction output amounts, in order to make a Guarantee Transaction
with relatively higher transaction fee. So, either of MT or GT can be
broadcasted or toke place in next block independently.
> When Bob tries to broadcast the "guarantee transaction" he will get an error:
> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
Here is the part which I am not sure you are right about it. I do not
know in detail and I'm not sure how miners will react to the two
double-spend transactions and which one they will prefer.
Will they use the first seen transaction for block pre-image, or will
use the transaction with higher transaction fee?
We need the help of Bitcoin core developers to clarify this transaction
selection mechanism.
If miners prefer the highest fee my scenario still is valid. But if
miners always keep the first transaction received and drop subsequent
transactions, I have three different solution to solve that I will
explain in later posts.
> 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he is connected
> to the internet, otherwise if he loses connection to the internet or energy supply,
> Alice attack will succeed entirely with 100% chances.
> So this means Bob needs to always be online like forever and ever.
Somehow you are right. Definitely Bob can delegate this task to a
doc-watcher, pretty much like watch-tower in Lightning, but due to the
small amount of creditor's credits and the fact that this amount is
scattered among many different issuers, I removed this part from the
original design of Sabu architecture.
BTW major creditors, such as stores that receives debt-documents worth
thousands of dollars a day, should (and better say must) always be
online to protect their money. This job also creates a safe margin for
other creditors.
IMHO at the moment the protocol is good enough to start, but we can
always talk about improving the protocol.
> The 3rd one is hypothetical and you don't even have to answer it:
> 3. How does Bob (first creditor) spend the coins received /
> how does Bob become an issuer himself in relation to Dave (another creditor)?
> What happens if Alice tries to fraud Bob after Bob spent its Sabu credit to Dave?
> Dave has to hold all parent "guarantee transactions" and watch the network for
> any potential fraudulent transactions that cancels his credit?
I already explained it in response of Billy here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html
just look for “how normal transactions happen in their entirety.”
Looking forward to hear from core developers about “how miners will
react to the two double-spend transactions and which one they will
prefer”.
Regards
Raymo
On 2021-08-09 00:03, s7r wrote:
> raymo via bitcoin-dev wrote:
>
> TL,DR: you were explained by ZmnSCPxj why this protocol will not work.
> The possibility for just one party to sign will not work. I will
> explain again why but in much more simpler description.
>
>
>> Check out this simple transaction to learn more about how the system
>> works.
>> Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
>> she can spend it by create a transaction and sign it and broadcast it to
>> Bitcoin network.
>> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
>> Satoshi from Alice in exchange.
>> Alice gets this 5$ and prepare a Main transaction that represents this
>> liability of Alice to Bob.
>>
>> Main Transaction (20,000 Sat input):
>> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
>> has to pay 3,000 as BTC fee)
>> * Alice (issuer): 6,000 Sat
>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
>> This is a valid transaction and both Bob and/or Alice can send it to
>> Bitcoin network, but none of them are interested in doing so. Because
>> they will lose 5,000 Satoshi of their own money as Bitcoin transaction
>> fee.
>>
>> Alongside this transaction Alice (the issuer) has to create the
>> Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
>> not consider the deal completed. The Guarantee Transaction is another
>> valid Bitcoin transaction. It is created based on Main Transaction and
>> will cut a part of Bob and Alice money in favor of transaction fee.
>>
>> Guarantee Transaction (20,000 Sat input):
>> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
>> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from
>> Bob) + 3,480 (from Al-ice) = 15,739 Sat
>>
>> The Guarantee Transaction applies when the issuer does not live up to
>> its promise and intends to spend the promised UTXO(s) in a way other
>> than that agreed upon. We already knew the fact that Sabu is not a
>> custodial solution, neither a M of N signature schema. As a result, the
>> UTXO owner always can spend the already promised UTXO(s) in Sabu
>> protocol or out of Sabu on Bitcoin blockchain, Contrary to what was
>> promised.
>> When the Alice (issuer) breaks such a promise and sends the fraudulent
>> transaction to the Bitcoin network, Bob's wallet realizes that she
>> (issuer) is spending the promised UTXO(s) and it sends the Guarantee
>> Transaction(s) to the network as a last resort. The miners will face two
>> (or more) transactions which are spending same UTXO(s), but one of them
>> is paying notably higher Bitcoin transaction fee, thus they chose the
>> highest fee payer transaction, which is the Guarantee Transaction. The
>> miner will put the Guarantee Transaction in next block and reject the
>> rest double-spend transactions. Certainly, poor Bob cannot recoup all
>> his Satoshis. But he can retrieve a portion of his money and forces
>> Alice to lose some of her money as well. tit for tat!
>> Because of this mechanism, the issuer will try to not cheat on creditor.
>>
>> By the way there are some attacks that have very small chance to succeed
>> but the risk to reward ratio for these scenarios are too high to be
>> considered as a real possible attack threat. I will review them a little
>> later in this post.
>>
>>
>
> You said that the guarantee transaction is created based on Main
> Transaction, how do you mean? If it is a child transaction of the Main
> Transaction it already doesn't work because Alice needs to broadcast
> the *Main Transaction* to the blockchain in order for the Guarantee
> transaction to be accepted, and of she does this, Bob doesn't care
> because the transaction pays to him already the correct agreed amount.
> If you did not mean this, still it won't work, because
>
> Simple:
> 1. Alice will create transaction #3, or call it
> Sabu-killing-transaction (20,000 Sat input):
> * Alice (issuer): 15,000 Sat
> * BTC Fee: 5,000 Sat
>
> PERIOD.
>
> When Bob tries to broadcast the "guarantee transaction" he will get an
> error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much
> larger fee in the guarantee transaction will not matter. You have to
> assume a miner will violate the Bitcoin protocol and somehow drop
> Sabu-killing-transaction from mempool and consider the Guarantee
> transaction only. This is very unlikely to happen and you might also
> need connection direct with the miners because most full nodes will
> not even accept the Guarantee transaction to their mempools in order
> to further broadcast it until it reaches the miners.
>
> With the simple attack described above Alice's chance to fraud Bob
> are, from my point of view, 99%.
>
> (the only way to replace a transaction is Replace-By-Fee but this
> implies the transaction that IS TO BE REPLACED has a certain flag set,
> and it is optional).
>
> Given the Sabu-Killing-transaction comes first, Alice will of course
> create it without this flag set so even if you add to Sabu the
> requirement of RBF enabled to the Guarantee transaction it will not
> work, because it's the other way around.
>
>
> The second question is just for an observation that it has no real
> benefits over Lightning even if #1 wasn't true:
>
> 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure
> he is connected to the internet, otherwise if he loses connection to
> the internet or energy supply, Alice attack will succeed entirely with
> 100% chances. So this means Bob needs to always be online like forever
> and ever.
>
> The 3rd one is hypothetical and you don't even have to answer it:
> 3. How does Bob (first creditor) spend the coins received / how does
> Bob become an issuer himself in relation to Dave (another creditor)?
> What happens if Alice tries to fraud Bob after Bob spent its Sabu
> credit to Dave? Dave has to hold all parent "guarantee transactions"
> and watch the network for any potential fraudulent transactions that
> cancels his credit?
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
[not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
@ 2021-08-09 20:22 ` raymo
0 siblings, 0 replies; 41+ messages in thread
From: raymo @ 2021-08-09 20:22 UTC (permalink / raw)
To: Chris Riley; +Cc: bitcoin-dev
Hi Chris,
Thanks for your detailed answer. So, as you answered there is an
uncertainty about this case. For me, even this uncertainty would be a
good point to start. Because if the miners realize the potentiality for
increasing revenue under Sabu protocol, very soon they will want to
update their transaction selecting mechanism priorities, even before
occurring the first real attack on the protocol in “production
software”. This upgrade in Bitcoin protocol will eliminate uncertainty
totally.
How hard do you think it will be this upgrade on protocol?
IMO the most important thing will be the consensus on the implementation
of these changes, while the code upgrading won't be a difficult
technical issue.
If it were difficult to agree on a Bitcoin core protocol change, we
might be able to achieve our goals by changing the Stratum protocol.
Unlike miners who would welcome that offer, full-nodes without hash
power would probably not be interested in upgrading the software. Maybe
because they do not want to disrupt the broadcasting of transactions by
relying double-spend transactions.
I'm not sure if the normal full nodes (without hash power) use the same
software that miners use. If not, we have to fight on two fronts to
upgrade the software.
Again, thanks for your fast and flourish reply :-)
Raymo
On 2021-08-09 18:03, Chris Riley wrote:
>> I'm not sure how miners will react to the two double-spend
> transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or will
> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
> transaction selection mechanism. If miners
>> prefer the highest fee my scenario still is valid. But if miners
> always keep the first transaction received
>> and drop subsequent transactions,
> Hi,
>
> Miners have the incentive to accept the highest fee transaction
> whenever they see it. That does not imply that miners _will_ accept
> the highest fee transaction they see for a variety of reasons. If a
> transaction does not signal RBF (BIP 125) then in general a "first
> seen" rule is applied, if a transaction does signal RBF, then in
> general the highest fee is prefered. Since this is an untrusted
> network, a miner could use RBF even for transactions that don't signal
> it, since she could claim she saw it first, assuming the miner was
> aware of it which might imply it was submitted directly since the
> network might not relay a higher fee transaction for a non-RBF
> transaction. Or a miner could see the first transaction and include
> it in a block just after the RBF transaction is broadcast but before
> the block is propagated. etc
>
> So there is only a question of probabilities: in general miners
> prefer the highest fee for RBF transactions and in general, miners
> will not replace a non-RBF transaction with a later one. However,
> nothing is guaranteed given it is an untrusted network and people
> could use non-standard rules for selection of what transactions are
> included in a block.
>
> :-)
>
> On Mon, Aug 9, 2021 at 12:57 PM raymo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hi s7r,
>> I already answered to ZmnSCPxj's comments.
>>
>> Let’s go to yours.
>>
>>> If it is a child transaction of the Main Transaction
>> Sorry for my shortcoming in English, because it caused the
>> misunderstanding of proposal.
>> There is not any relation between Main Transaction and Guarantee
>> transaction. when I said “the Guarantee Transaction is created
>> based on
>> Main Transaction” I was intended only the numbers. I mean the
>> output
>> amounts of Guarantee Transaction are calculated relatively based on
>> Main
>> Transaction output amounts, in order to make a Guarantee Transaction
>> with relatively higher transaction fee. So, either of MT or GT can
>> be
>> broadcasted or toke place in next block independently.
>>
>>> When Bob tries to broadcast the "guarantee transaction" he will
>> get an error:
>>> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
>> Here is the part which I am not sure you are right about it. I do
>> not
>> know in detail and I'm not sure how miners will react to the two
>> double-spend transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or
>> will
>> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
>> transaction
>> selection mechanism.
>> If miners prefer the highest fee my scenario still is valid. But if
>> miners always keep the first transaction received and drop
>> subsequent
>> transactions, I have three different solution to solve that I will
>> explain in later posts.
>>
>>> 2. The creditor (Bob) has to leave his wallet running 24x7 and
>> ensure he is connected
>>> to the internet, otherwise if he loses connection to the internet
>> or energy supply,
>>> Alice attack will succeed entirely with 100% chances.
>>> So this means Bob needs to always be online like forever and ever.
>> Somehow you are right. Definitely Bob can delegate this task to a
>> doc-watcher, pretty much like watch-tower in Lightning, but due to
>> the
>> small amount of creditor's credits and the fact that this amount is
>> scattered among many different issuers, I removed this part from the
>> original design of Sabu architecture.
>> BTW major creditors, such as stores that receives debt-documents
>> worth
>> thousands of dollars a day, should (and better say must) always be
>> online to protect their money. This job also creates a safe margin
>> for
>> other creditors.
>> IMHO at the moment the protocol is good enough to start, but we can
>> always talk about improving the protocol.
>>
>>> The 3rd one is hypothetical and you don't even have to answer it:
>>> 3. How does Bob (first creditor) spend the coins received /
>>> how does Bob become an issuer himself in relation to Dave (another
>> creditor)?
>>> What happens if Alice tries to fraud Bob after Bob spent its Sabu
>> credit to Dave?
>>> Dave has to hold all parent "guarantee transactions" and watch the
>> network for
>>> any potential fraudulent transactions that cancels his credit?
>> I already explained it in response of Billy here
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html
>>
>> just look for “how normal transactions happen in their
>> entirety.”
>>
>> Looking forward to hear from core developers about “how miners
>> will
>> react to the two double-spend transactions and which one they will
>> prefer”.
>>
>> Regards
>> Raymo
>>
>> On 2021-08-09 00:03, s7r wrote:
>>> raymo via bitcoin-dev wrote:
>>>
>>> TL,DR: you were explained by ZmnSCPxj why this protocol will not
>> work.
>>> The possibility for just one party to sign will not work. I will
>>> explain again why but in much more simpler description.
>>>
>>>
>>>> Check out this simple transaction to learn more about how the
>> system
>>>> works.
>>>> Consider Alice as an issuer. She owns a UTXO worth 20,000
>> Satoshi. So,
>>>> she can spend it by create a transaction and sign it and
>> broadcast it to
>>>> Bitcoin network.
>>>> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys
>> 12,000
>>>> Satoshi from Alice in exchange.
>>>> Alice gets this 5$ and prepare a Main transaction that represents
>> this
>>>> liability of Alice to Bob.
>>>>
>>>> Main Transaction (20,000 Sat input):
>>>> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000,
>> but Bob
>>>> has to pay 3,000 as BTC fee)
>>>> * Alice (issuer): 6,000 Sat
>>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
>>>> This is a valid transaction and both Bob and/or Alice can send it
>> to
>>>> Bitcoin network, but none of them are interested in doing so.
>> Because
>>>> they will lose 5,000 Satoshi of their own money as Bitcoin
>> transaction
>>>> fee.
>>>>
>>>> Alongside this transaction Alice (the issuer) has to create the
>>>> Guarantee Transaction as well and deliver it to Bob. Otherwise,
>> Bob will
>>>> not consider the deal completed. The Guarantee Transaction is
>> another
>>>> valid Bitcoin transaction. It is created based on Main
>> Transaction and
>>>> will cut a part of Bob and Alice money in favor of transaction
>> fee.
>>>>
>>>> Guarantee Transaction (20,000 Sat input):
>>>> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 =
>> 1,740 Sat
>>>> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520
>> Sat
>>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260
>> (from
>>>> Bob) + 3,480 (from Al-ice) = 15,739 Sat
>>>>
>>>> The Guarantee Transaction applies when the issuer does not live
>> up to
>>>> its promise and intends to spend the promised UTXO(s) in a way
>> other
>>>> than that agreed upon. We already knew the fact that Sabu is not
>> a
>>>> custodial solution, neither a M of N signature schema. As a
>> result, the
>>>> UTXO owner always can spend the already promised UTXO(s) in Sabu
>>>> protocol or out of Sabu on Bitcoin blockchain, Contrary to what
>> was
>>>> promised.
>>>> When the Alice (issuer) breaks such a promise and sends the
>> fraudulent
>>>> transaction to the Bitcoin network, Bob's wallet realizes that
>> she
>>>> (issuer) is spending the promised UTXO(s) and it sends the
>> Guarantee
>>>> Transaction(s) to the network as a last resort. The miners will
>> face two
>>>> (or more) transactions which are spending same UTXO(s), but one
>> of them
>>>> is paying notably higher Bitcoin transaction fee, thus they chose
>> the
>>>> highest fee payer transaction, which is the Guarantee
>> Transaction. The
>>>> miner will put the Guarantee Transaction in next block and reject
>> the
>>>> rest double-spend transactions. Certainly, poor Bob cannot recoup
>> all
>>>> his Satoshis. But he can retrieve a portion of his money and
>> forces
>>>> Alice to lose some of her money as well. tit for tat!
>>>> Because of this mechanism, the issuer will try to not cheat on
>> creditor.
>>>>
>>>> By the way there are some attacks that have very small chance to
>> succeed
>>>> but the risk to reward ratio for these scenarios are too high to
>> be
>>>> considered as a real possible attack threat. I will review them a
>> little
>>>> later in this post.
>>>>
>>>>
>>>
>>> You said that the guarantee transaction is created based on Main
>>> Transaction, how do you mean? If it is a child transaction of the
>> Main
>>> Transaction it already doesn't work because Alice needs to
>> broadcast
>>> the *Main Transaction* to the blockchain in order for the
>> Guarantee
>>> transaction to be accepted, and of she does this, Bob doesn't care
>>> because the transaction pays to him already the correct agreed
>> amount.
>>> If you did not mean this, still it won't work, because
>>>
>>> Simple:
>>> 1. Alice will create transaction #3, or call it
>>> Sabu-killing-transaction (20,000 Sat input):
>>> * Alice (issuer): 15,000 Sat
>>> * BTC Fee: 5,000 Sat
>>>
>>> PERIOD.
>>>
>>> When Bob tries to broadcast the "guarantee transaction" he will
>> get an
>>> error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The
>> much
>>> larger fee in the guarantee transaction will not matter. You have
>> to
>>> assume a miner will violate the Bitcoin protocol and somehow drop
>>> Sabu-killing-transaction from mempool and consider the Guarantee
>>> transaction only. This is very unlikely to happen and you might
>> also
>>> need connection direct with the miners because most full nodes
>> will
>>> not even accept the Guarantee transaction to their mempools in
>> order
>>> to further broadcast it until it reaches the miners.
>>>
>>> With the simple attack described above Alice's chance to fraud Bob
>>> are, from my point of view, 99%.
>>>
>>> (the only way to replace a transaction is Replace-By-Fee but this
>>> implies the transaction that IS TO BE REPLACED has a certain flag
>> set,
>>> and it is optional).
>>>
>>> Given the Sabu-Killing-transaction comes first, Alice will of
>> course
>>> create it without this flag set so even if you add to Sabu the
>>> requirement of RBF enabled to the Guarantee transaction it will
>> not
>>> work, because it's the other way around.
>>>
>>>
>>> The second question is just for an observation that it has no real
>>> benefits over Lightning even if #1 wasn't true:
>>>
>>> 2. The creditor (Bob) has to leave his wallet running 24x7 and
>> ensure
>>> he is connected to the internet, otherwise if he loses connection
>> to
>>> the internet or energy supply, Alice attack will succeed entirely
>> with
>>> 100% chances. So this means Bob needs to always be online like
>> forever
>>> and ever.
>>>
>>> The 3rd one is hypothetical and you don't even have to answer it:
>>> 3. How does Bob (first creditor) spend the coins received / how
>> does
>>> Bob become an issuer himself in relation to Dave (another
>> creditor)?
>>> What happens if Alice tries to fraud Bob after Bob spent its Sabu
>>> credit to Dave? Dave has to hold all parent "guarantee
>> transactions"
>>> and watch the network for any potential fraudulent transactions
>> that
>>> cancels his credit?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
2021-08-09 0:03 ` s7r
2021-08-09 16:22 ` raymo
@ 2022-11-02 17:30 ` Erik Aronesty
1 sibling, 0 replies; 41+ messages in thread
From: Erik Aronesty @ 2022-11-02 17:30 UTC (permalink / raw)
To: s7r, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
>
> (the only way to replace a transaction is Replace-By-Fee but this
> implies the transaction that IS TO BE REPLACED has a certain flag set,
> and it is optional).
>
1. full rbf is becoming standard. tx without full rbf can just be
rejected as a part of the sabu protocol
2. that's fine. watchtowers can be used to fix this that only have the
ability to stop attacks in progress. guarantee transactions can include a
small watchtower fee for your favorite always-on watchtower service
3. all parties need to maintain sabu state (it's just another mempool)
[-- Attachment #2: Type: text/html, Size: 849 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2022-11-02 17:30 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
2021-06-18 1:42 ` Erik Aronesty
2021-06-18 13:44 ` Alex Schoof
2021-06-18 20:00 ` raymo
2021-06-19 21:14 ` Erik Aronesty
2021-06-18 13:37 ` Erik Aronesty
2021-06-18 20:22 ` raymo
2021-06-20 0:53 ` ZmnSCPxj
2021-06-26 21:54 ` raymo
2021-06-27 4:53 ` ZmnSCPxj
2021-06-27 11:05 ` raymo
2021-06-28 5:20 ` ZmnSCPxj
2021-06-28 6:29 ` raymo
2021-06-28 8:23 ` James Hilliard
2021-06-28 9:52 ` raymo
2021-06-28 11:28 ` James Hilliard
2021-06-28 16:33 ` raymo
2021-06-28 15:28 ` ZmnSCPxj
2021-06-28 16:58 ` raymo
2021-06-28 17:58 ` Alex Schoof
2021-06-28 19:07 ` raymo
2021-06-29 21:42 ` ZmnSCPxj
2021-06-30 12:21 ` raymo
2021-06-28 17:29 ` Tao Effect
2021-06-28 17:38 ` raymo
2021-06-28 18:05 ` Ricardo Filipe
2021-06-20 1:59 ` James Hilliard
2021-06-22 18:20 ` Billy Tetrud
2021-07-01 20:11 ` raymo
2021-07-01 20:49 ` Erik Aronesty
2021-07-01 22:15 ` raymo
2021-07-02 17:57 ` Billy Tetrud
2021-07-03 8:02 ` raymo
2021-07-07 3:20 ` Billy Tetrud
2021-07-17 15:50 ` raymo
2021-07-17 18:54 ` Tao Effect
2021-08-08 9:11 ` raymo
2021-08-09 0:03 ` s7r
2021-08-09 16:22 ` raymo
[not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
2021-08-09 20:22 ` raymo
2022-11-02 17:30 ` Erik Aronesty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox