đź“… Original date posted:2021-06-18
đź“ť Original message:Hi Alex,
The 10 Sat fee is Sabu-transaction-fee and goes to issuers to
incentivize UTXO owners to put their money in system and prepare money
transfer service for the Creditors. pretty much like banks.
This number is my suggestion, but can be changed to something higher or
lesser or even being customized for each issuer(Banks with high fee and
more speed/reliability or less fee and less speed but more distributed).
Typically Issuers put an UTXOs worth 40,000 Sat and issue a
debt-document(transaction) worth 20,000 or less. So issuer can use
thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document
(worth 20,000,000 debit) and earn significant Sabu-transaction-fee
daily.
No need to say the issuer also dictates the fiat to BTC exchange rate in
first step, and can earn even more benefits by selling BTC a little
higher than market price. The target would be penny savers which
potentially buy very small amount each time(teenagers or people with low
income specially).
About your double-spend scenario please write a clear scenario and use
the conventional terms such as issuer, creditor, MT, GT, CT etc... to
study its feasibility. Maybe there are corner cases which I missed. So
we will fix it as well.
About p2p Gossiping, you are right. There is latency but it doesn't hurt
the consensus on Sabu protocol. Please consider figure 7. inter
creditors Bitcoin transfer as an example. By the way in all money
transactions between issuer -> creditor or creditor->creditor, the
receiver wallet "always" controls the doc-watcher client to be ensure
the fact that the delivered debt-document(aka transaction) to receiver
wallet, already exist on the doc-watcher sites. If that particular
document exist in doc-watcher , the wallet consider it as a valid
transaction, otherwise creditor won't accept the deal as a settled deal.
>I think you will end up reinventing a lot of the problems solved by bitcoin.
No, that's not true. Because I proposed a complementary tool for Bitcoin
which came from a different point of view. Note the fact that Sabu
protocol realizes a different model of decentralization. In Sabu there
is no DLT at all and all consensus are between small set of users (most
of time between an issuer and a creditor). In Sabu there is no
obligation for everyone know everything about every transaction. Each
participant only knows about its interest. Alongside there is a gossip
mirroring of all transaction that flood to the clients a light weight
information of a tuple [UTXO, transaction-Merkle-root]. These gossip
nodes (doc-watchers) are not corruptible since it works in a simple
proof-of-existance (true-positive) model. And no one can mutilate it by
censor transactions.
>Why did you pick email as the RPC mechanism to transfer these notes?
First of all I have to explain a part of design spec. Each mobile wallet
has to have a fresh email address which is dedicated to Sabu protocol
activities. The wallet has access to this email address and read, delete
inbox or send emails. So the spam or spam filter problem is not the
case.
In my opinion email is the ONLY neutral, free (non proprietary) and open
protocol/technology for communication in the world that its
infrastructure is well-established and is accessible all over the glob.
Even in countries with low internet speed.
I intentionally chose email as main communication mean. Because non
technical people can easily make an email address or change it
(comparing establish a website or use an static IP) and notify the
friends about new address and they can easily send and receive Bitcoin
just by knowing email addresses. Once the user install the
Sabu-supporter-wallet (called Gazin), he will config and record his 12
seed words. The wallet also creates the PGP Pub/Priv key pair based on
these 12 words seeds and signs the wallet email address too. All are
take place behind the scene and user only sees its wallet is ready. So
these 12 worlds are users wealth protector and identity sovereignty as
well. User adds friends wallet email address or scan its QR code. The
rest is PGP encrypted emails(handshake, agreement and transactions)
between two wallets. No one needs to ask a central service to have an
account. Pure Cypher punk users can run their personal email server or
even better their freedombox https://freedomboxfoundation.org. So no one
can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his
account. The wallet owner can easily and fast immigrate to new email
address (or even different email service provider) and sign new address
and notify to his friends circle with no real barrier.
While these are all benefits of using email as a user identifier in
system, there could be some privacy issue in some levels. For example
most email service provider impose some sort of KYC or ask user mobile
number, but there are other providers which are respecting users
privacy. implicitly prevalence of Sabu users creates more demands for
this privacy-respector-companies, so these companies will be increased.
Another issue would be global passive spying or full-pipe project will
find who do transaction with who. Since communications are PGP encrypted
it won't be clear who is sender or receiver or how much is transferred
or even if they are really parties in a transaction or it is just a fake
noise connection! The forward secrecy also would be another issues.
although these are mostly the privacy issues rather than Sabu intrinsic
problems.
Some other disadvantage of email is latency, so some third parties would
easily provide the optional alternate communication services for wallet,
e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to
compensate the speed and/or privacy issues. These are all communication
means and the wallet can simply use one or more methods in parallel.
Later we will see the wallet users will choose which solution. Speed vs
privacy, sovereignty and independence.
Regards
Raymo
On 2021-06-18 13:44, Alex Schoof wrote:
> A few questions/comments:
>
> Why is there a 10 sat fee on each tx? Where does that fee go?
>
> I don’t think this design sufficiently protects against double
> spends by the “issuer” (the person who actually has the UTXO).
> Your guarantee tx mechanism only really covers the case where someone
> tries to double spend part of a UTXO balance (in other words, if the
> penalty lost is less than the value gained by doing a double spend,
> its worth it to double spend, and in a world where you’re passing
> around digital IOUs, it’s easy to make it worth it). Later in the
> post, you mention that there will be a p2p network to gossip fund
> transfers and that will prevent an issuer from double spending. The
> problem there is that network latency is non-zero, large network
> partitions are both real and common, and nodes can come and go anytime
> (hardware failure, power failure, network partition healing, just
> because they feel like it, etc). Different nodes on the network might
> hear about different, conflicting transactions. Nodes will need a way
> to all come to consensus on what the right set of “sent notes” is.
> I think you will end up reinventing a lot of the problems solved by
> bitcoin.
>
> Why did you pick email as the RPC mechanism to transfer these notes?
> Email is going to add variable amounts of latency and things like spam
> filters will cause issues.
>
> Alex
>
> On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> for very small transactions, this seems to make a hell of a lot of
>> sense.
>>
>> it's like lightning, but with no limits, no routing protocols...
>> everything is guaranteed by relative fees and the cost-of-theft.
>>
>> pretty cool.
>>
>> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hi,
>>> I have a proposal for improve Bitcoin TPS and privacy, here is the
>> post.
>>>
>>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>> https://bitcointalk.org/index.php?topic=5344020.0
>>> Can you please read it and share your idea about it.
>>>
>>> Cheers
>>> Raymo
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> --
>
> Alex Schoof
raymo at riseup.net [ARCHIVE] /
npub1ud…v4p33
2023-06-07 22:54:52
in reply to nevent1q…9yug
Author Public Key
npub1ud4hzyxp4mr66vj2phl4g7f5u3snl9mxfc09q482dzh6qqd5u9es9v4p33Published at
2023-06-07 22:54:52Event JSON
{
"id": "093d8d4238a890fdbc889cf70be5f05b08ec3fd9c6b9dcfb046de11511ded5c4",
"pubkey": "e36b7110c1aec7ad324a0dff547934e4613f97664e1e5054ea68afa001b4e173",
"created_at": 1686178492,
"kind": 1,
"tags": [
[
"e",
"3ebd7f928d32c4622a16cd89abc93b788e957c8f9779a11f751efe89917c69af",
"",
"root"
],
[
"e",
"13456656ae938e0c88805347b70b08a6350d9da7849c9a1301636a0b108ee294",
"",
"reply"
],
[
"p",
"faa7cfc9ee0c9b69494bd7640c40d266cfcae2aa009a89c3be36825b8900ecfc"
]
],
"content": "📅 Original date posted:2021-06-18\n📝 Original message:Hi Alex,\n\nThe 10 Sat fee is Sabu-transaction-fee and goes to issuers to\nincentivize UTXO owners to put their money in system and prepare money\ntransfer service for the Creditors. pretty much like banks.\nThis number is my suggestion, but can be changed to something higher or\nlesser or even being customized for each issuer(Banks with high fee and\nmore speed/reliability or less fee and less speed but more distributed).\n\nTypically Issuers put an UTXOs worth 40,000 Sat and issue a\ndebt-document(transaction) worth 20,000 or less. So issuer can use\nthousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document\n(worth 20,000,000 debit) and earn significant Sabu-transaction-fee\ndaily.\nNo need to say the issuer also dictates the fiat to BTC exchange rate in\nfirst step, and can earn even more benefits by selling BTC a little\nhigher than market price. The target would be penny savers which\npotentially buy very small amount each time(teenagers or people with low\nincome specially).\n\nAbout your double-spend scenario please write a clear scenario and use\nthe conventional terms such as issuer, creditor, MT, GT, CT etc... to\nstudy its feasibility. Maybe there are corner cases which I missed. So\nwe will fix it as well.\n\nAbout p2p Gossiping, you are right. There is latency but it doesn't hurt\nthe consensus on Sabu protocol. Please consider figure 7. inter\ncreditors Bitcoin transfer as an example. By the way in all money\ntransactions between issuer -\u003e creditor or creditor-\u003ecreditor, the\nreceiver wallet \"always\" controls the doc-watcher client to be ensure\nthe fact that the delivered debt-document(aka transaction) to receiver\nwallet, already exist on the doc-watcher sites. If that particular\ndocument exist in doc-watcher , the wallet consider it as a valid\ntransaction, otherwise creditor won't accept the deal as a settled deal.\n\n\u003eI think you will end up reinventing a lot of the problems solved by bitcoin. \n\nNo, that's not true. Because I proposed a complementary tool for Bitcoin\nwhich came from a different point of view. Note the fact that Sabu\nprotocol realizes a different model of decentralization. In Sabu there\nis no DLT at all and all consensus are between small set of users (most\nof time between an issuer and a creditor). In Sabu there is no\nobligation for everyone know everything about every transaction. Each\nparticipant only knows about its interest. Alongside there is a gossip\nmirroring of all transaction that flood to the clients a light weight\ninformation of a tuple [UTXO, transaction-Merkle-root]. These gossip\nnodes (doc-watchers) are not corruptible since it works in a simple\nproof-of-existance (true-positive) model. And no one can mutilate it by\ncensor transactions.\n\n\u003eWhy did you pick email as the RPC mechanism to transfer these notes?\n\nFirst of all I have to explain a part of design spec. Each mobile wallet\nhas to have a fresh email address which is dedicated to Sabu protocol\nactivities. The wallet has access to this email address and read, delete\ninbox or send emails. So the spam or spam filter problem is not the\ncase.\n\nIn my opinion email is the ONLY neutral, free (non proprietary) and open\nprotocol/technology for communication in the world that its\ninfrastructure is well-established and is accessible all over the glob.\nEven in countries with low internet speed.\nI intentionally chose email as main communication mean. Because non\ntechnical people can easily make an email address or change it\n(comparing establish a website or use an static IP) and notify the\nfriends about new address and they can easily send and receive Bitcoin\njust by knowing email addresses. Once the user install the\nSabu-supporter-wallet (called Gazin), he will config and record his 12\nseed words. The wallet also creates the PGP Pub/Priv key pair based on\nthese 12 words seeds and signs the wallet email address too. All are\ntake place behind the scene and user only sees its wallet is ready. So\nthese 12 worlds are users wealth protector and identity sovereignty as\nwell. User adds friends wallet email address or scan its QR code. The\nrest is PGP encrypted emails(handshake, agreement and transactions)\nbetween two wallets. No one needs to ask a central service to have an\naccount. Pure Cypher punk users can run their personal email server or\neven better their freedombox https://freedomboxfoundation.org. So no one\ncan stop user from using this system(Bitcoin + Sabu + Gazin) or ban his\naccount. The wallet owner can easily and fast immigrate to new email\naddress (or even different email service provider) and sign new address\nand notify to his friends circle with no real barrier.\nWhile these are all benefits of using email as a user identifier in\nsystem, there could be some privacy issue in some levels. For example\nmost email service provider impose some sort of KYC or ask user mobile\nnumber, but there are other providers which are respecting users\nprivacy. implicitly prevalence of Sabu users creates more demands for\nthis privacy-respector-companies, so these companies will be increased.\nAnother issue would be global passive spying or full-pipe project will\nfind who do transaction with who. Since communications are PGP encrypted\nit won't be clear who is sender or receiver or how much is transferred\nor even if they are really parties in a transaction or it is just a fake\nnoise connection! The forward secrecy also would be another issues.\nalthough these are mostly the privacy issues rather than Sabu intrinsic\nproblems.\nSome other disadvantage of email is latency, so some third parties would\neasily provide the optional alternate communication services for wallet,\ne.g Matrix, Nym network, Onion, I2P, classic central servers, etc to\ncompensate the speed and/or privacy issues. These are all communication\nmeans and the wallet can simply use one or more methods in parallel.\nLater we will see the wallet users will choose which solution. Speed vs\nprivacy, sovereignty and independence.\n \nRegards\nRaymo\n\nOn 2021-06-18 13:44, Alex Schoof wrote:\n\u003e A few questions/comments:\n\u003e \n\u003e Why is there a 10 sat fee on each tx? Where does that fee go? \n\u003e \n\u003e I don’t think this design sufficiently protects against double\n\u003e spends by the “issuer” (the person who actually has the UTXO).\n\u003e Your guarantee tx mechanism only really covers the case where someone\n\u003e tries to double spend part of a UTXO balance (in other words, if the\n\u003e penalty lost is less than the value gained by doing a double spend,\n\u003e its worth it to double spend, and in a world where you’re passing\n\u003e around digital IOUs, it’s easy to make it worth it). Later in the\n\u003e post, you mention that there will be a p2p network to gossip fund\n\u003e transfers and that will prevent an issuer from double spending. The\n\u003e problem there is that network latency is non-zero, large network\n\u003e partitions are both real and common, and nodes can come and go anytime\n\u003e (hardware failure, power failure, network partition healing, just\n\u003e because they feel like it, etc). Different nodes on the network might\n\u003e hear about different, conflicting transactions. Nodes will need a way\n\u003e to all come to consensus on what the right set of “sent notes” is.\n\u003e I think you will end up reinventing a lot of the problems solved by\n\u003e bitcoin. \n\u003e \n\u003e Why did you pick email as the RPC mechanism to transfer these notes?\n\u003e Email is going to add variable amounts of latency and things like spam\n\u003e filters will cause issues. \n\u003e \n\u003e Alex\n\u003e \n\u003e On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e for very small transactions, this seems to make a hell of a lot of\n\u003e\u003e sense.\n\u003e\u003e\n\u003e\u003e it's like lightning, but with no limits, no routing protocols...\n\u003e\u003e everything is guaranteed by relative fees and the cost-of-theft.\n\u003e\u003e\n\u003e\u003e pretty cool.\n\u003e\u003e\n\u003e\u003e On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e I have a proposal for improve Bitcoin TPS and privacy, here is the\n\u003e\u003e post.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180\n\u003e\u003e\u003e https://bitcointalk.org/index.php?topic=5344020.0\n\u003e\u003e\u003e Can you please read it and share your idea about it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers\n\u003e\u003e\u003e Raymo\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e -- \n\u003e \n\u003e Alex Schoof",
"sig": "bd14c5513204dd2891fbb2b92b12b3259c63665a9f871923fdceff054a087dcf09ad3b076d4c462272f4966c3a61abdf43668b5d1648eee437afeb1d72f9bb46"
}