Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-09 Thread Mr. Lee Chiffre via bitcoin-dev


>
> === Combining multi-transaction with routing ===
>
> Routing and multi-transaction must be combined to get both benefits. If
> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> easy with this configuration:
>
>  Alice
> (6 BTC) (8 BTC) (1 BTC)
>|   |   |
>|   |   |
>v   v   v
>   Bob
> (5 BTC) (5 BTC) (5 BTC)
>|   |   |
>|   |   |
>v   v   v
> Charlie
> (9 BTC) (5 BTC) (1 BTC)
>|   |   |
>|   |   |
>v   v   v
> Dennis
> (7 BTC) (4 BTC) (4 BTC)
>|   |   |
>|   |   |
>v   v   v
>  Alice
>






Great work Chris and you have my respects for your contributions to
Bitcoin. A concern I have with bitcoin is scalability and privacy. Both
are important. The reasons people bash on Monero is also the same issue
Bitcoin has. The very large transaction size to achieve acceptable privacy
on a distributed financial network. Im not shilling Monero here. I am only
saying that bitcoin transactions with similar privacy properties are at
least equally as large as Monero transactions. Coinjoin on Monero can be
compared to ring signatures in Monero from the view of using decoys to
help conceal the source. From this proposal is this to say that
transactions will be at least 12 times larger in size to achieve the
property of privacy that bitcoin is currently missing?

Another thing to consider is that if coinswaps cannot be sent as a payment
then a coinswap needs to take place after every transaction to keep the
privacy and unlinkability from your other bitcoin transactions.

I always thought that CoinSwap would be and is a very much needed thing
that needs developed. The ability to swap coins with other people in a
trustless way and way that is not linkable to the public blockchain. But
how can this be scalable at all with the multiple branches and layers?
This is a good idea in theory but my concern would be the scalability
issues this creates.

Do you have any comments on this?
Thank you


-- 
lee.chif...@secmail.pro
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35

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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-09 Thread Mr. Lee Chiffre via bitcoin-dev


> Coinjoin on Monero can be
> compared to ring signatures in Monero from the view of using decoys to
> help conceal the source. From this proposal is this to say that
> transactions will be at least 12 times larger in size to achieve the
> property of privacy that bitcoin is currently missing?
>


This was a typo. Coinjoin on BITCOIN, can be compared to ring signatures
in Monero form the view of using decoys to help conceal the source.


The same thing that makes monero transactions large and a scalability
concern is the same thing that bitcoin suffers from with using privacy
focused transactions.

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


Re: [bitcoin-dev] Stamping transaction

2020-06-09 Thread Chris Riley via bitcoin-dev
Hello,

Just a few comments.

>But there is no guarantee that ndes should keep all of them from the
genesis. It depends. Maybe some nodes want to keep  all the transactions,
some part of them and might nothing.
There is no guarantee that nodes keep them all from the genesis now, nodes
can turn on pruning if the operator doesn't desire to keep all the
transactions from the genesis block
(https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning).
Likewise, light clients may not keep any transaction history.

>Also we can think about check pointing. When a new node connects to the
network, it doesn't need to validate all the blocks since genesis. It can
start validating from a checkpoint.
>Transactions have their own way to survive. Owner of the coin can keep the
history of his transactions.
There have been some checkpoint discussions on here too, which have
discussed the pros and cons of them.
see, e.g.:
site:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ checkpointand:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016001.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017209.html

Without introducing trusted people, how can you prove that the "owner" is
person A or B without verification from the genesis block?  For example, A
or B could claim to be the owner and provide an altered client with an
altered checkpoint to "prove" it.

>Anytime the bitcoin community decides to make a hard-fork, you might
consider this change as well
>From reading the initial bitcoin paper, many proposals etc since and having
been around the "bitcoin community" for 9 years, I think that this change
has a very, very small chance of ever happening because full transaction
verification is an important part of the blockchain bank.   Not to say this
isn't a useful, interesting, informative, and educational discussion, but
it seems unlikely to happen.  Likewise,  it could lead to something related
that would be likely to occur, so full discussions like this are useful.

Regards,  :-)
Chris

On Tue, Jun 9, 2020 at 7:20 AM Mostafa Sedaghat joo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good day ZmnSCPxj
>
> As I said before, I don't expect a hard fork for this change. I wanted to
> share my thoughts with you guys. Anytime the bitcoin community decides to
> make a hard-fork, you might consider this change as well.
> I believe decoupling transactions from the block is beautiful.
>
>  About transaction verification,
> Transactions have their own way to survive. Owner of the coin can keep the
> history of his transactions.
> But there is no guarantee that ndes should keep all of them from the
> genesis. It depends. Maybe some nodes want to keep  all the transactions,
> some part of them and might nothing.
> Also we can think about check pointing. When a new node connects to the
> network, it doesn't need to validate all the blocks since genesis. It can
> start validating from a checkpoint.
>
> And also adding 32 bits to the header of translation (which won't be saved
> inside the block) is not a big deal.
>
>
> Adios,
> Mostafa
>
>
>
> On Sun, Jun 7, 2020 at 11:01 PM ZmnSCPxj  wrote:
>
>> Good morning Mostafa,
>>
>>
>> > The main point of stamping transactions is decoupling transactions from
>> the block.
>> >
>> > Blockchain size matters
>> > SegWit is a good witness that shows blockchain size matters.
>> Nowadays, Data storage is cheap and easy, but that doesn't mean it's a
>> simple matter. If you need to have a data-center to keep a copy of a
>> blockchain, then you are far from a decentralization system.
>> >
>> > A Solution
>> > Stamping transaction is a simple idea to keep the size of the
>> blockchain as small as possible. The question that I was looking to answer
>> is how we can decouple the transaction from the blocks.
>> > Who cares about the transaction that happened 10 years ago. In the real
>> world you may go to your bank and ask them to give you transaction history.
>> But they probably have limits. They might say we just only keep the last 3
>> months in our system.
>>
>> Stamping transaction is not how you would be able to keep **blockchain**
>> size low.
>>
>> The reason why very old history is retained is that, if a new node is
>> brought up, you need to prove to that node that you are in fact the correct
>> owner of the current coins.
>> Thus the entire history of Bitcoin is needed when starting a new node,
>> and why archive nodes exist.
>>
>> You might argue that banks do not do that, and that is because we want to
>> do better than banks; we know that existing currency systems have not only
>> the "official" minter, but also many "unofficial" minters (commonly called
>> counterfeiters) which dilute the value of the currency.
>> It is this insistence on a full accounting of the provenance for every
>> satoshi that separates Bitcoin from previous currency systems; bank fraud
>> exists, and it hides in such 

Re: [bitcoin-dev] Stamping transaction

2020-06-09 Thread Mostafa Sedaghat joo via bitcoin-dev
Good day ZmnSCPxj

As I said before, I don't expect a hard fork for this change. I wanted to
share my thoughts with you guys. Anytime the bitcoin community decides to
make a hard-fork, you might consider this change as well.
I believe decoupling transactions from the block is beautiful.

 About transaction verification,
Transactions have their own way to survive. Owner of the coin can keep the
history of his transactions.
But there is no guarantee that ndes should keep all of them from the
genesis. It depends. Maybe some nodes want to keep  all the transactions,
some part of them and might nothing.
Also we can think about check pointing. When a new node connects to the
network, it doesn't need to validate all the blocks since genesis. It can
start validating from a checkpoint.

And also adding 32 bits to the header of translation (which won't be saved
inside the block) is not a big deal.


Adios,
Mostafa



On Sun, Jun 7, 2020 at 11:01 PM ZmnSCPxj  wrote:

> Good morning Mostafa,
>
>
> > The main point of stamping transactions is decoupling transactions from
> the block.
> >
> > Blockchain size matters
> > SegWit is a good witness that shows blockchain size matters.
> Nowadays, Data storage is cheap and easy, but that doesn't mean it's a
> simple matter. If you need to have a data-center to keep a copy of a
> blockchain, then you are far from a decentralization system.
> >
> > A Solution
> > Stamping transaction is a simple idea to keep the size of the blockchain
> as small as possible. The question that I was looking to answer is how we
> can decouple the transaction from the blocks.
> > Who cares about the transaction that happened 10 years ago. In the real
> world you may go to your bank and ask them to give you transaction history.
> But they probably have limits. They might say we just only keep the last 3
> months in our system.
>
> Stamping transaction is not how you would be able to keep **blockchain**
> size low.
>
> The reason why very old history is retained is that, if a new node is
> brought up, you need to prove to that node that you are in fact the correct
> owner of the current coins.
> Thus the entire history of Bitcoin is needed when starting a new node, and
> why archive nodes exist.
>
> You might argue that banks do not do that, and that is because we want to
> do better than banks; we know that existing currency systems have not only
> the "official" minter, but also many "unofficial" minters (commonly called
> counterfeiters) which dilute the value of the currency.
> It is this insistence on a full accounting of the provenance for every
> satoshi that separates Bitcoin from previous currency systems; bank fraud
> exists, and it hides in such sloppy techniques as deleting old transaction
> records.
>
> Work has been done to have client-side validation (i.e. the owner of a
> coin keeps the entire history, and when paying, you hand over the entire
> history of your coin to the payee, instead of everyone validating every
> transaction).
> Look up Peter Todd for some initial work on this.
>
>
> > Implementation
> >
> > > First off, the proposed mechanism can be made into a softfork by using
> an unspendable `scriptPubKey` with 0 output value.
> > SoftFork is not possible here. Because the transaction will not be saved
> inside the block (only tx hashes). Block format needs to be changed.
> Therefore the block will be invalid.
>
> That greatly reduces the chances your proposal will get into Bitcoin; you
> would need to have very good advantages to counterbalance the tremendous
> risk that hardforks introduce in the continuity of the coin.
>
> Bitcoin has never gone through a hardfork that has not instead created a
> new cryptocurrency, so any solution that requires a hardfork is going to be
> unlikely to be accepted by everyone.
>
> > > Engineering-wise, block validation now needs to memorize the last N
> block hashes.
> > I don't think we need to memorize the last N block hashes.  We can have
> something like:
> > ```
> > Current_Height - Height_Of(tx.stamp) <= N
> > ```
>
> ...
>
>
> `Height_Of()` would basically be a mapping from block hashes to block
> heights, with the number of elements equal to the height of the blockchain,
> and thus continuously growing.
> Thus, validation is expected to become more expensive as the blockchain
> grows.
>
> Since stamped transactions have a time-to-live anyway, instead you can use
> a *set* of the most recent N block hashes.
> Then you simply check if the stamp is in the set.
> This creates a data structure that is constant in size (at each block, you
> remove the block from N blocks ago), which is good for validation.
>
> > Incentives
> > I think Stamping transactions have nothing to do with the
> incentivization mechanism.  Forgive me if I couldn't get your point.
>
> A stamped tranasction has a stamp, an unstamped transaction has no stamp.
> The stamped transaction is larger because of the stamp.
> Larger transactions are more expensive because