Oleg Andreev [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-10 to 2021-08-26
💬 Posted a total of 16 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:03:16

- reply

📅 Original date posted:2021-08-08
📝 Original message:
I agree with Jeremy. Dust limit works due to design accident: that outputs are not encrypted. But outputs are private business and the real issue is only the cost of utxo set storage born by every user. There are two ways to address this:
1) either make ppl pay for renting that storage (which creates a ton of problems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is perfectly solved by Utreexo.
But looking at the private data because you can is a hack that creates issues of its own.
> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead.
>
> The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.
>
> Matt
>
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
>
> It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway.
>
>> 2) dust outputs can be used in various authentication/delegation smart contracts
>
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs.
>
>> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light <https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light>) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail)
>
> This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol).
>
>> 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
>
> These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to encourage people to use values which make sense economically to "clean up" after they're done with them. If people want to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN.
>
>> 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
>
> This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the standardness rules around the dust limit to allow for CT.
>
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
>
> 3) The significant costs to every miner and full node operator.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-09 12:40:47

- reply

2023-06-07 22:58:14

- reply

📅 Original date posted:2021-08-26
📝 Original message:It is worth checking out Ivy lang Playground by Dan Robinson, but AFAIK, it's not actively maintained. It compiles contracts to Bitcoin Script: https://www.ivylang.org/bitcoin
> On 24. Aug 2021, at 16:08, Andrew Poelstra via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Simplicity does not compile to Bitcoin Script, and Sapio assumes extensions
> to Bitcoin Script that are not currently part of the consensus code.
>
>
> On Tue, Aug 24, 2021 at 03:36:29PM +0800, Gijs van Dam via bitcoin-dev wrote:
>> Hi,
>>
>>
>> Bitcoin does not have a virtual machine. But you do have [Miniscript][1],
>> [Min.sc][2], [Simplicity][3] and [Sapio][4]. These are all higher level
>> languages that compile to Bitcoin Script. Sapio is "just" Rust, so that
>> might fit your setting best.
>>
>> By the way, this question also has an answer on [Bitcoin Stackexchange][5]
>> which is a great resource for questions like this.
>>
>> [1]: http://bitcoin.sipa.be/miniscript/
>> [2]: https://min.sc/
>> [3]: https://github.com/ElementsProject/simplicity
>> [4]: https://learn.sapio-lang.org/
>> [5]:
>> https://bitcoin.stackexchange.com/questions/108261/is-there-a-tool-like-ethereum-evm-at-present-for-bitcoin-script
>>
>> On Tue, Aug 24, 2021 at 2:55 PM Null Null via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Is there a tool like Ethereum EVM at present? Users can write bitcoin
>>> scripts in a syntax just like python(or like other programming language);
>>> through this tool, they can be translated into bitcoin original scripts; it
>>> sounds like a new programming language has been invented.
>>>
>>> In my opinion， Bitcoin script programming is based on reverse Polish
>>> expression; this is not friendly to programmers;
>>>
>>> In fact, Bitcoin's opcode expression ability is very rich, and it may be
>>> unfriendly, which has affected the promotion of Bitcoin in the technical
>>> community.
>>>
>>> Hope for hearing some voice about this.
>>>
>>> Best wish.
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:57:50

- reply

📅 Original date posted:2021-08-08
📝 Original message:I agree with Jeremy. Dust limit works due to design accident: that outputs are not encrypted. But outputs are private business and the real issue is only the cost of utxo set storage born by every user. There are two ways to address this:
1) either make ppl pay for renting that storage (which creates a ton of problems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is perfectly solved by Utreexo.
But looking at the private data because you can is a hack that creates issues of its own.
> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead.
>
> The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.
>
> Matt
>
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
>
> It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway.
>
>> 2) dust outputs can be used in various authentication/delegation smart contracts
>
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs.
>
>> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light <https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light>) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail)
>
> This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol).
>
>> 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
>
> These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to encourage people to use values which make sense economically to "clean up" after they're done with them. If people want to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN.
>
>> 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
>
> This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the standardness rules around the dust limit to allow for CT.
>
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
>
> 3) The significant costs to every miner and full node operator.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:16

- reply

📅 Original date posted:2019-02-01
📝 Original message:A follow-up comment: I've have sent this email right before Pieter's talk on miniscript at Stanford yesterday. I want to express my appreciation to the thinking about scripts/contracts that Pieter, Andy, Greg have been promoting for long time. These ideas influenced a lot the design decisions in ZkVM: "blockchain as a court", very limited functionality and clarity of scripts, and, as Pieter laid out yesterday, composition of policies. These are all the same values that I'm trying to reflect in ZkVM, that's why i think it might be interesting to this mailing list.
Also, Neha Narula asked a question this morning:
> Isn't this a DoS vector, in that an attacker could generate a lot of expensive code to execute in the VM which would then be rejected once the checks get executed? If so, how critical is this deferred execution of point operations to your design?
The answer: hopefully it's not a DoS vector, we are working on this right now. Programs for `call` and `delegate` have to be statically built into the transaction bytecode string, and cannot be constructed within the VM (so it's very similar to P2SH). ZkVM is similar to Bitcoin Script in that the execution cost is proportional to the program length: one cannot make a short program that would use loops or recursion into dynamically constructed programs to exhibit arbitrary validation cost. For those familiar with TxVM released last year, we are removing loops and dynamic program construction, and gas-like "runlimit" with them from ZkVM.
Another feature is inspired by old proposal by Pieter (IIRC) to treat checksig as all-or-nothing. ZkVM does not do dynamic branching based on outcomes of expensive operations. Signature checks, predicate tree traversal - all have to unconditionally succeed.
1. This makes the program execution (w/o ECC ops) very fast and proportional to the length of the program.
2. Then, all the collected ECC ops give precise metric of how expensive the rest of the validation would be.
3. Plus, the constraint system proof blob (that comes with the transaction) by itself gives an exact measurement of the bulletproofs validation cost.
The upstream protocol ("blockchain rules") can have soft- or hard- caps on both program length and amount of ECC operations (similar to the limit on sig checks per block in Bitcoin). That said, we haven't drilled into specifics what these caps should be and how they should be enforced, that's still in the works.
> On Jan 31, 2019, at 15:44 , Oleg Andreev <oleganza at gmail.com> wrote:
>
> Hi,
>
> We've been working for a thing called ZkVM [1] for the last few weeks. It is a "blockchain virtual machine" in the spirit of Bitcoin, with multi-asset transfers and zero-knowledge programmable constraints.
>
> As a part of its design, there is a "Predicate Tree" — a variant of Taproot by Greg Maxwell [2] and G'root by Anthony Towns [3] that I would like to present here. Hopefully it is useful to the discussion, and I would appreciate any feedback.
>
> ## Background
>
> In ZkVM there are linear types Contract and Value (in addition to plain data types), where Contract also implements "object capabilities" pattern: Contract "locks" a collection of data and Values under a "predicate" which is represented by a single group element ("point" in ECC terms). The predicate can be "satisfied" in a number of allowed ways which makes the contract unlock its contents, e.g. release the stored Value which can then be locked in a new unspent output.
>
> ## Predicate Tree
>
> Predicate is a point that represents one of three things, which allows composing conditions in an arbitrary tree:
>
> 1. Public key
> 2. Program
> 3. Disjunction of two other predicates
>
> Public key allows representing N-of-N signing conditions (and M-of-N with proper threshold key setup, although small combinations like 2-of-3 can be non-interactively represented as a tree of 3 combinations of 2-of-2 conditions):
>
> P = x*B (x is a secret, B is a primary generator point)
>
> Program commitment is a P2SH-like commitment:
>
> P = hash2scalar(program)*B2 (B2 is orthogonal to B, so one cannot sign for P, but must reveal the program)
>
> Disjunction (asymmetric to allow happy-path signing with the left predicate):
>
> P = L + hash2scalar(L,R)*B
>
>
> ## VM instructions
>
> To use the predicate trees, ZkVM provides 4 instructions:
>
> 1. `signtx` to verify the signature over the transaction ID treating the predicate as a pubkey.
> 2. `call` to reveal the committed program and execute it.
> 3. `left`/`right` to replace the contract's predicate with one of the sub-predicates in a disjunction.
> 4. `delegate` to check a signature over a program and execute that program (pay-to-signed-program pattern).
>
> More details are in the ZkVM spec: https://github.com/interstellar/zkvm/blob/main/spec/ZkVM.md#signtx
>
> `call` and `delegate` differ in that `call` reveals and runs a pre-arranged program (like in P2SH), while `delegate` allows choosing the program later which can be signed with a pre-arranged public key. `delegate` also enables use cases for SIGHASH: if a specific output or outputs or constraints must be signed, they can be represented by such program snippet. Likewise, a "revocation token" for the payment channel (LN) can be implemented with `delegate` instruction.
>
>
> ## Performance
>
> For performance, the following rules are built into ZkVM:
>
> 1. All point operations are deferred. Signature checks, disjunction proofs, program commitment proofs - are not executed right away, but deferred and verified in a batch after the VM execution is complete. This enables significant savings, especially since half or third of the terms reuse static points B and B2.
> 2. `signtx` does not accept individual signatures, but uses a single aggregated signature for the whole transaction. All the pubkeys are remembered in a separate set and combined via MuSig-style [4] protocol to check the single 64-byte signature over txid in the end of the VM execution. In other words, signature aggregation is not optional for `signtx` (signatures over txid). Note: the `delegate` instruction permits arbitrary programs, so it uses one signature per program.
>
>
> ## What is different from Taproot/G'root
>
> (1) No pure hash-based MAST: each time one peels off a layer of a tree, there's an ECC check which is more expensive than pure-hash merkle path check, but makes the design simpler and all ECC ops are batched alongside bulletproofs R1CS verification statement, making the performance difference unimportant.
>
> (2) There is no designated blinding factor or a pubkey with the program commitment like in G'root. This is not something i'm particularly sure about, but will lay out the current rationale:
> 1. The happy-path one-time-key normally acts as a sufficient blinding factor for the program.
> 2. If the program needs a blinding factor, it can be embedded as a `<garbage> drop`.
> 3. The combo of "sign + programmatic constraints" is done by having instructions inside the program that wrap the value(s) in a transient contract with the required pubkey and leaving it on the stack.
>
>
> ## References
>
> [1] https://github.com/interstellar/zkvm
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html
> [4] https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190201/20c16a4b/attachment.html>

2023-06-07 18:16:09

- reply

📅 Original date posted:2019-01-31
📝 Original message:Hi,
We've been working for a thing called ZkVM [1] for the last few weeks. It is a "blockchain virtual machine" in the spirit of Bitcoin, with multi-asset transfers and zero-knowledge programmable constraints.
As a part of its design, there is a "Predicate Tree" — a variant of Taproot by Greg Maxwell [2] and G'root by Anthony Towns [3] that I would like to present here. Hopefully it is useful to the discussion, and I would appreciate any feedback.
## Background
In ZkVM there are linear types Contract and Value (in addition to plain data types), where Contract also implements "object capabilities" pattern: Contract "locks" a collection of data and Values under a "predicate" which is represented by a single group element ("point" in ECC terms). The predicate can be "satisfied" in a number of allowed ways which makes the contract unlock its contents, e.g. release the stored Value which can then be locked in a new unspent output.
## Predicate Tree
Predicate is a point that represents one of three things, which allows composing conditions in an arbitrary tree:
1. Public key
2. Program
3. Disjunction of two other predicates
Public key allows representing N-of-N signing conditions (and M-of-N with proper threshold key setup, although small combinations like 2-of-3 can be non-interactively represented as a tree of 3 combinations of 2-of-2 conditions):
P = x*B (x is a secret, B is a primary generator point)
Program commitment is a P2SH-like commitment:
P = hash2scalar(program)*B2 (B2 is orthogonal to B, so one cannot sign for P, but must reveal the program)
Disjunction (asymmetric to allow happy-path signing with the left predicate):
P = L + hash2scalar(L,R)*B
## VM instructions
To use the predicate trees, ZkVM provides 4 instructions:
1. `signtx` to verify the signature over the transaction ID treating the predicate as a pubkey.
2. `call` to reveal the committed program and execute it.
3. `left`/`right` to replace the contract's predicate with one of the sub-predicates in a disjunction.
4. `delegate` to check a signature over a program and execute that program (pay-to-signed-program pattern).
More details are in the ZkVM spec: https://github.com/interstellar/zkvm/blob/main/spec/ZkVM.md#signtx
`call` and `delegate` differ in that `call` reveals and runs a pre-arranged program (like in P2SH), while `delegate` allows choosing the program later which can be signed with a pre-arranged public key. `delegate` also enables use cases for SIGHASH: if a specific output or outputs or constraints must be signed, they can be represented by such program snippet. Likewise, a "revocation token" for the payment channel (LN) can be implemented with `delegate` instruction.
## Performance
For performance, the following rules are built into ZkVM:
1. All point operations are deferred. Signature checks, disjunction proofs, program commitment proofs - are not executed right away, but deferred and verified in a batch after the VM execution is complete. This enables significant savings, especially since half or third of the terms reuse static points B and B2.
2. `signtx` does not accept individual signatures, but uses a single aggregated signature for the whole transaction. All the pubkeys are remembered in a separate set and combined via MuSig-style [4] protocol to check the single 64-byte signature over txid in the end of the VM execution. In other words, signature aggregation is not optional for `signtx` (signatures over txid). Note: the `delegate` instruction permits arbitrary programs, so it uses one signature per program.
## What is different from Taproot/G'root
(1) No pure hash-based MAST: each time one peels off a layer of a tree, there's an ECC check which is more expensive than pure-hash merkle path check, but makes the design simpler and all ECC ops are batched alongside bulletproofs R1CS verification statement, making the performance difference unimportant.
(2) There is no designated blinding factor or a pubkey with the program commitment like in G'root. This is not something i'm particularly sure about, but will lay out the current rationale:
1. The happy-path one-time-key normally acts as a sufficient blinding factor for the program.
2. If the program needs a blinding factor, it can be embedded as a `<garbage> drop`.
3. The combo of "sign + programmatic constraints" is done by having instructions inside the program that wrap the value(s) in a transient contract with the required pubkey and leaving it on the stack.
## References
[1] https://github.com/interstellar/zkvm
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html
[4] https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/

2023-06-07 18:00:00

- reply

📅 Original date posted:2017-04-12
📝 Original message:(This is a sketch, not a fully-formed proposal, just to kick off the discussion.)
Confidential Transactions (by GMaxwell & Poelstra) require a new accounting model,
new representation of numbers (EC points as Pedersen commitments) and range proofs
per number. Setting aside performance and bandwidth concerns (3-4Kb per output,
50x more signature checks), how would we deploy that feature on Bitcoin network
in the most compatible manner?
I'll try to present a sketch of the proposal. I apologize if this discussion already
happened somewhere, although I couldn't find anything on this subject, apart from Elements
sidechain proposal, of course.
At first glance we could create a new extblock and transaction format, add a protocol to
"convert" money into and from such extblock, and commit to that extblock from the
outer block's coinbase transaction. Unfortunately, this opens gates to a flood of
debates such as what should be the block size limit in such block, should we
take opportunity to fix over 9000 of pet-peeve issues with existing transactions
and blocks, should we adjust inflation schedule, insert additional PoW, what would
Satoshi say etc. Federated sidechain suffers from the same issues, plus adds
concerns regarding governance, although it would be more decoupled, which is useful.
I tried to look at a possibility to make the change as compatible as possible,
sticking confidential values right into the existing transaction structure and
see how that would look like. As a nice bonus, confidential transactions would have
to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P
We start with a segwit-enabled script versioning and introduce 2 new script versions:
version A has an actual program concatenated with the commitment, while version B
has only the commitment and allows mimblewimble usage (no signatures, non-interactive
cut-through etc). Legacy cleartext amount can nicely act as "min value" to minimize
the range proof size, and range proofs themselves are provided separately in the
segregated witness payload.
Then, we soft fork additional rules:
1. In non-coinbase tx, sum of commitments on inputs must balance with sum of commitments
on the outputs plus the cleartext mining fee in the witness.
2. Range proof can be confidential, based on borromean ring signature.
3. Range proof can be non-confidential, consisting of an amount and raw blinding factor.
4. Tx witness can have an excess value (cf. MW) and cleartext amount for a miner's fee.
5. In coinbase tx, total plaintext reward + commitments must balance with subsidy,
legacy fees and new fees in the witness.
6. Extra fees in the witness must be signed with the excess value's key.
The confidential transactions use the same UTXO set, can be co-authored with plaintext inputs/outputs
using legacy software and maybe even improve scalability by compressing on-chain transactions
using mimblewimble cut-through.
The rules above could have been made more complicated with export/import logic to allow users
converting their coins to and from confidential ones, but that would require
more complex support from miners to respect and merge outputs representing "plaintext value bank",
mutate export transactions, which in turn requires introduction of a non-malleable TxID
that excludes miner-adjustable export/import outputs.
The rules above have a nice side effect that miners, being the minters of confidential coins,
can sell them at a premium, which creates an incentive for them to actually support
that feature and work on improving performance of rangeproof validation (e.g. in GPUs).
Would love to hear comments and criticism of that approach.
Thanks!
Oleg.

2023-06-07 17:44:18

- reply

📅 Original date posted:2015-11-10
📝 Original message:OP_0 gives a zero length byte array because OP_0 == 0x00 which is equivalent to pushdata with zero length.
OP_EQUAL compares byte strings as-is. So it will push "false" because empty string is not the same as a single-byte string with 0x00 byte in it. Value "false" in turn is encoded as empty string, just like result of OP_0.
> On 06 Nov 2015, at 10:37, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I meant not to use the OP_PUSH opcodes to do the push.
>
> Does OP_0 give a zero length byte array?
>
> Would this script return true?
>
> OP_0
> OP_PUSHDATA1 (length = 1, data = 0)
> OP_EQUAL
>
> The easiest definition is that OP_0 and OP_1 must be used to push the data and not any other push opcodes.
>
>
> On Fri, Nov 6, 2015 at 9:32 AM, Oleg Andreev <oleganza at gmail.com <mailto:oleganza at gmail.com>> wrote:
>
> > One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array.
> >
> > They should also be minimally encoded but that is covered by previous rules.
>
> These two lines contradict each other. Minimally-encoded "zero" is an array of length zero, not one. I'd suggest defining this explicitly here as "IF/NOTIF argument must be either zero-length array or a single byte 0x01".
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/8c16a920/attachment.html>

2023-06-07 17:44:17

- reply

📅 Original date posted:2015-11-06
📝 Original message:> One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array.
>
> They should also be minimally encoded but that is covered by previous rules.
These two lines contradict each other. Minimally-encoded "zero" is an array of length zero, not one. I'd suggest defining this explicitly here as "IF/NOTIF argument must be either zero-length array or a single byte 0x01".

2023-06-07 15:44:11

- reply

📅 Original date posted:2015-07-31
📝 Original message:> On 31 Jul 2015, at 11:56, Thomas Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
>> If I was a miner and you want me to include your transaction for free,
>> you're asking me to give you money
>
> What?
>
> Ask yourself; why do miners include transactions at all? What it the incentive
> if there really is only less than 0.8% of income to be derived from fees?
>
> Miners don't get payed by fees. They won't need to get payed by fees for
> decades to come. Maybe you want to re-do your math, it seems off.
Fees should be compared not with the total revenue, but with the profit margin. If a miner invested/spends 24 BTC per block and earns 0.25 in fees, then his total profit is 1.25 BTC per block and fees comprise a whopping 20% of the profit.
Today I think profit margins are quite high, so fees do not matter much. But it's not hard to imagine that in just a couple of years BTC may appreciate a lot more, attract more investors and even bigger foundries to, say, print chips and mine right at the foundry, thus driving profit margins lower. Fees will begin to matter regardless of the total subsidy.
Just some hypothetical calculation.
Lets say in 2015 one block costs 5 BTC and fees bring 0.25 BTC. Profit is thus 20.25 BTC and fees comprise 1.2% of that amount.
Lets say in late 2016 halving happens, BTC appreciates and resulting competition drives up the cost to 6 BTC (yes, BTC itself is more expensive, but so is the profit too, so increased competition must drive down the profit margin). Now the block brings 6.75 BTC in profit. Fees, if unchanged now make 4% of the total profit.
If all goes well, in mid 2020 another halving happens (6.25 BTC/block) and even if the BTC-denominated cost stays the same miner now will earn 0.25 BTC profit from subsidy and fees now can account for 100% of that amount.
Of course it's a very rough estimate and most likely to be far from reality, but it shows how fees can begin to matter rather quickly under pressure of separate factors: halving and growing valuation and mining competition.

2023-06-07 15:32:34

- reply

📅 Original date posted:2015-04-28
📝 Original message:> On 27 Apr 2015, at 21:21, Peter Todd <pete at petertodd.org> wrote:
>
> Even right now there are edge cases without
> good solutions, like how in a multisig environment any of the key
> holders can mutate transactions.
Can't we add requirement for RFC6979 signatures to mitigate this? Of course, multiple signers can still mutate transaction by choosing a different set (but not the order, thankfully) of signatures. Or when a single signer has multiple participating keys.
In some interesting to me scenarios mutation by signer is not critical: it is mutation by non-signers that creates a problem. Do you know of any edge cases when non-signers can mutate transactions which are not covered by BIP62? What would be a more robust approach than "whack-a-mole" to work around mutability? (Normalized tx ids?)

2023-06-07 15:31:22

- reply

📅 Original date posted:2015-02-26
📝 Original message:Thanks for references. Yeah, I don't need X509 signing (if I could use certificates, I wouldn't need to include PR in the URL in the first place).
I presume you used "BITCOIN:-<payment request>" instead of "bitcoin:?r=somescheme://<payment request>" to make it more compact.
I also tried to look up Base43, but I could not find any info on how it is specifically optimized for QR codes. Could you enlighten me?
> On 26 Feb 2015, at 10:32, Andreas Schildbach <andreas at schildbach.de> wrote:
>
> Yeah, you'd be limited to simple usecases. X509 signing or lots of
> outputs will make the QR code hard to scan. However, if all you want to
> do is send to a custom script (without using P2SH) I invite you to have
> a look at
>
> https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/ui/InputParser.java#L86
>
> https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Qr.java#L134
>
> https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Base43.java
>
> Basically it's "BITCOIN:-" plus the payment request in Base43 encoded
> form. I picked Base43, because that's optimized for QR codes.
>
>
> On 02/24/2015 04:58 PM, Oleg Andreev wrote:
>> Hi,
>>
>> I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal is to allow device to generate a multi-output payment request on its own, without relying on the server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no additional authentication needed.
>>
>> I'd like something like this:
>>
>> bitcoin:?r=data://<base64url-encoded-payment-request>
>>
>> If there's no standard for that, would it be a good idea to extend BIP72 this way?
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>>
>
>

2023-06-07 15:31:22

- reply

📅 Original date posted:2015-02-26
📝 Original message:> Base43 is the same as any BaseX standard, but using a different alphabet
> (43 characters). It's meant to be used for efficiently storing binary
> data into QR codes. The alphabet is picked to match the 'Alphanumeric'
> input mode of QR codes as closely as possible, but at the same time be
> allowed in URIs.
Does it mean Base58 or Base64 take more space in QR code than Base43? Do you have an estimate of the gains?

2023-06-07 15:31:21

- reply

📅 Original date posted:2015-02-24
📝 Original message:Hi,
I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal is to allow device to generate a multi-output payment request on its own, without relying on the server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no additional authentication needed.
I'd like something like this:
bitcoin:?r=data://<base64url-encoded-payment-request>
If there's no standard for that, would it be a good idea to extend BIP72 this way?

2023-06-07 15:30:14

- reply

📅 Original date posted:2015-02-12
📝 Original message:> I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can "get away" with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients.
>
> Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer.
Here's value-free assessment of the issue here:
1. Zero-conf txs are unsafe.
2. We'd all want to have a safer instant payments solution if possible.
3. As a social artifact, today zeroconf txs happen to work for some people in some situations.
4. Replace-by-fee will break #3 and probably hasten development of #2.
The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner.
I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons).
TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/6fddaefd/attachment.html>

2023-06-07 15:30:11

- reply

📅 Original date posted:2015-02-12
📝 Original message:> On 12 Feb 2015, at 13:49, Mike Hearn <mike at plan99.net> wrote:
> If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks.
How about a Ripple-like IOU-based payment network that is 100% decentralized, for "dumb and daily" payments only? IOUs will propagate from node to node and will trusted because of a "joint escrow" transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it's being "cleared" by debtor via a real BTC transaction or simply by "closing" the contract transaction with correct proportion on outputs to pay off the debt.
Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible "paths" and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they'll have to lock up huge amount of money. This puts natural limit on centralization or associated risk.
Example:
I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee:
Me: $10 -> $9.99 (Alice) -> $9.98 (Bob) -> $9.97 (Merchant).
Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is >1%).
Pros:
- Decentralized.
- Mere seconds to settle a payment.
- Infinite scalability (no global consensus). Each payment involves 5-7 nodes only.
- No trusted parties or federation (trust is "purchased" using "joint escrow" txs on blockchain)
- No funny currency, IOUs denominated in BTC.
- No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local.
Political problems solved:
- No need to debate zeroconf transactions. We don't *need* them anymore to buy a coffee.
- No need to debate block size limit. It'd still be nice to raise it when needed, but for 99% of transactions we'll have a good decentralized solution off-chain, so the issue is less pressing.
Cons:
- Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can't be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/4105f17b/attachment.html>

2023-06-07 15:30:01

- reply

📅 Original date posted:2015-02-10
📝 Original message:> Let's say you're visiting an international webshop. But they don't ship to your country. Wouldn't you want to know that before your start filling the cart? With this, your wallet / browser extension could tell you right away that you can't shop there. No time wasted!
Why my wallet has to do anything with me being in some country? The webshop may detect my location and tell me if they ship to where I'm currently in. Why should I associate more private information (my location) with my wallet than strictly necessary? Why should I automatically advertise my shipping address to every webshop without my explicit consent?
The wallet must be convenient only as much as it allows for better security and privacy, but not trading off security and privacy for some unrelated convenience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/ef9b1d00/attachment.html>