Re: [bitcoin-dev] Taproot Fields for PSBT

2021-06-28 Thread Salvatore Ingala via bitcoin-dev
Hi Andrew,

Thanks for the clarification, I was indeed reading it under the mistaken
assumption that only one leaf would be added to the PSBT.

En passant, for the less experienced readers, it might be helpful if the
key types that are possibly present multiple times (with different keydata)
were somehow labeled in the tables.

Best,
Salvatore Ingala
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev

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
>  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 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread Alex Schoof via bitcoin-dev
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,
> > 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread Ricardo Filipe via bitcoin-dev
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 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
> >>  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev
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
>>  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


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev


> 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


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev

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  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 

Re: [bitcoin-dev] Taproot Fields for PSBT

2021-06-28 Thread Andrew Chow via bitcoin-dev
Hi Salvatore,

On 6/28/21 6:03 AM, Salvatore Ingala wrote:

> Hi Andrew,
>
> I just have a small suggestion on this proposal.
>
> On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev 
>  wrote:
>
>> | Taproot Leaf Script
>> | PSBT_IN_TAP_LEAF_SCRIPT = 0x15
>> | 
>> | The control block for this leaf as specified in BIP 341. The control
>> block contains the merkle tree path to this leaf.
>> | 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread ZmnSCPxj via bitcoin-dev
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


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread James Hilliard via bitcoin-dev
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 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 

Re: [bitcoin-dev] BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols

2021-06-28 Thread Ben Carman via bitcoin-dev
> If nSequence is set it should apply only to the first input of the
transaction, if it has multiple inputs.

This could have complications with DLCs and dual funded lightning. In both 
protocols the ordering of the inputs is not know until both parties have 
revealed all of their inputs, and during the reveal the nSequence is given.  If 
we want DLCs and dual funded lightning to be compatible it would be better to 
have it define it as “at least one of the inputs of the transaction” instead of 
“it should apply only to the first input of the transaction”

benthecarman

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Taproot Fields for PSBT

2021-06-28 Thread Salvatore Ingala via bitcoin-dev
Hi Andrew,

I just have a small suggestion on this proposal.

On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> | Taproot Leaf Script
> | PSBT_IN_TAP_LEAF_SCRIPT = 0x15
> | 
> | The control block for this leaf as specified in BIP 341. The control
> block contains the merkle tree path to this leaf.
> | 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev

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
>  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, 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread James Hilliard via bitcoin-dev
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 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread raymo via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev