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 i
will cause issues.
>
> Alex
>
> On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> 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 proto
ts 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
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
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,
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 an
e
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
> w
tion 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
> 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 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 tra
n
> 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.
>
&
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
> 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 net
ress to avoid privacy/central system concerns
>
> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
> wrote:
>>
>> Hi Billy,
>> Sorry for late reply. Let’s jump in proposal.
>>
>> > Some more information about the benefits of this approach vs alterna
ging 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
>>>> 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
>>&
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/sca
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”.
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 b
19 matches
Mail list logo
