>
> (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.
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
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
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
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
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
> wrote:
>
> After introducing Sabu protocol as a solution for Bitcoin scaling
>
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
> 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
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
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
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
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 /
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
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
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
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
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
I believe Zman meant issuer.
raymo via bitcoin-dev 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
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
> 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
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
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
On Mon, Jun 28, 2021 at 3:52 AM 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
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
On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
wrote:
>
> Hi,
> I have
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
40 matches
Mail list logo
