Andreas M. Antonopoulos [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-06-06 to 2017-09-21
💬 Posted a total of 8 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-07 18:06:08

- reply

📅 Original date posted:2017-09-20
📝 Original message:This was very helpful at least to me, thank you
I've been struggling to follow the discussion of tail-call execution and
understand the options for implementing MAST. This clarified everything. I
can now follow the previous discussions.
On Sep 20, 2017 18:56, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Over the past few weeks I've been explaining the MERKLEBRANCHVERIFY
opcode and tail-call execution semantics to a variety of developers,
and it's come to my attention that the BIPs presentation of the
concept is not as clear as it could be. Part of this is the fault of
standards documents being standards documents whose first and foremost
responsibility is precision, not pedagogy.
I think there's a better way to explain this approach to achieving
MAST, and it's worked better in the face to face and whiteboard
conversations I've had. I'm forwarding it to this list in case there
are others who desire a more clear explanation of what the
MERKLEBRANCHVERIFY and tail-call BIPs are trying to achieve, and what
any of it has to do with MAST / Merklized script.
I've written for all audiences so I apologize if it starts of at a
newbie level, but I encourage you to skim, not skip as I quickly start
varying this beginner material in atypical ways.
Review of P2SH
It's easiest to explain the behavior and purpose of these BIPs by
starting with P2SH, which we are generalizing from. BIP 16 (Pay to
Script Hash) specifies a form of implicit script recursion where a
redeem script is provided in the scriptSig, and the scriptPubKey is a
program that verifies the redeem script hashes to the committed value,
with the following template:
HASH160 <hash> EQUAL
This script specifies that the redeem script is pulled from the stack,
its hash is compared against the expected value, and by fiat it is
declared that the redeem script is then executed with the remaining
stack items as arguments.
Sortof. What actually happens of course is that the above scriptPubKey
template is never executed, but rather the interpreter sees that it
matches this exact template format, and thereby proceeds to carry out
the same logic as a hard-coded behavior.
Generalizing P2SH with macro-op fusion
This template-matching is unfortunate because otherwise we could
imagine generalizing this approach to cover other use cases beyond
committing to and executing a single redeem script. For example, if we
instead said that anytime the script interpreter encountered the
3-opcode sequence "HASH160 <20-byte-push> EQUAL" it switched to
interpreting the top element as if it were a script, that would enable
not just BIP 16 but also constructs like this:
IF
HASH160 <hash-1> EQUAL
ELSE
HASH160 <hash-2> EQUAL
ENDIF
This script conditionally executes one of two redeem scripts committed
to in the scriptPubKey, and at execution only reveals the script that
is actually used. All an observer learns of the other branch is the
script hash. This is a primitive form of MAST!
The "if 3-opcode P2SH template is encountered, switch to subscript"
rule is a bit difficult to work with however. It's not a true EVAL
opcode because control never returns back to the top-level script,
which makes some important aspects of the implementation easier, but
only at the cost of complexity somewhere else. What if there are
remaining opcodes in the script, such as the ELSE clause and ENDIF in
the script above? They would never be executed, but does e.g. the
closing ENDIF still need to be present? Or what about the standard
pay-to-pubkey-hash "1Address" output:
DUP HASH160 <20-byte-key-hash> EQUALVERIFY CHECKSIG
That almost looks like the magic P2SH template, except there is an
EQUALVERIFY instead of an EQUAL. The script interpreter should
obviously not treat the pubkey of a pay-to-pubkey-hash output as a
script and recurse into it, whereas it should for a P2SH style
script. But isn't the distinction kinda arbitrary?
And of course the elephant in the room is that by choosing not to
return to the original execution context we are no longer talking
about a soft-fork. Work out, for example, what will happen with the
following script:
[TRUE] HASH160 <hash-of-[TRUE]> EQUAL FALSE
(It returns false on a node that doesn't understand generalized
3-opcode P2SH recursion, true on a node that does.)
Implicit tail-call execution semantics and P2SH
Well there's a better approach than trying to create a macro-op fusion
franken-EVAL. We have to run scripts to the end to for any proposal to
be a soft-fork, and we want to avoid saving state due to prior
experience of that leading to bugs in BIP 12. That narrows our design
space to one option: allow recursion only as the final act of a
script, as BIP 16 does, but for any script not just a certain
template. That way we can safely jump into the subscript without
bothering to save local state because termination of the subscript is
termination of the script as a whole. In computer science terms, this
is known as tail-call execution semantics.
To illustrate, consider the following scriptPubKey:
DUP HASH160 <20-byte-hash> EQUALVERIFY
This script is almost exactly the same as the P2SH template, except
that it leaves the redeem script on the stack rather than consuming
it, thanks to the DUP, while it _does_ consume the boolean value at
the end because of the VERIFY. If executed, it leaves a stack exactly
as it was, which we assume will look like the following::
<argN> ... <arg1> <redeemScript>
Now a normal script is supposed to finish with just true or false on
the stack. Any script that finishes execution with more than a single
element on the stack is in violation of the so-called clean-stack rule
and is considered non-standard -- not relayable and potentially broken
by future soft-fork upgrades. But so long as at least one bit of
<redeemScript> is set, it is interpreted as true and the script
interpreter would normally interpret a successful validation at this
point, albeit with a clean-stack violation.
Let's take advantage of that by changing what the script interpreter
does when a script finishes with multiple items remaining on the stack
and top-most one evaluates as true -- a state of affairs that would
pass validation under the old rules. Now instead the interpreter
treats the top-most item on the stack as a script, and tail-call
recurse into it, P2SH-style. In the above example, <redeemScript> is
popped off the stack and is executed with <arg1> ... <argN> remaining
on the stack as its arguments.
The above script can be interpreted in English as "Perform tail-call
recursion if and only if the HASH160 of the script on the top of the
stack exactly matches this 20-byte push." Which is, of course, what
BIP 16 accomplishes with template matching. However the implicit tail
call approach allows us to do much more than just P2SH!
For starters, it turns out that using HASH160 for P2SH was probably a
bad idea as it reduces the security of a multi-party constructed hash
to an unacceptable 80 bits. That's why segwit uses 256-bit hashes for
its pay to script hash format, for 128-bit security. Had we tail call
semantics instead of BIP 16, we could have just switched to a new
address type that decodes to the following script template instead:
DUP HASH256 <32-byte-hash> EQUALVERIFY
Ta-da, we're back to full 128-bit security with no changes to the
consensus code, just a new address version to target this script
template.
MAST with tail-call alone?
Or: an aside on general recursion
Our IF-ELSE Merklized Abstract Syntax Tree example above, rewritten to
use tail-call evaluation, might look like this (there are more compact
formulations possible, but our purpose here is not code golf):
IF
DUP HASH160 <hash-1> EQUALVERIFY
ELSE
DUP HASH160 <hash-2> EQUALVERIFY
ENDIF
Either execution pathway leaves us with one of the two allowed redeem
scripts on the top of the stack, and presumably its arguments beneath
it. We then execute that script via implicit tail-call.
We could write scripts using IF-ELSE branches or other tricks to
commit to more than two possible branches, although this unfortunately
scales linearly with the number of possible branches. If we allow the
subscript itself to do its own tail-call recursion, and its subscript
and so on, then we could nest these binary branches for a true MAST in
the original sense of the term.
However in doing so we would have enabled general recursion and
inherit all the difficulties that come with that. For example, some
doofus could use a script that consists of or has the same effect as a
single DUP to cause an infinite loop in the script interpreter. And
that's just the tip of the iceberg of problems general recursion can
bring, which stem generally from resource usage no longer being
correlated with the size of the witness stack, which is the primary
resource for which there are global limits.
This is fixable with a gas-like resource accounting scheme, which
would affect not just script but also mempool, p2p, and other
layers. And there is perhaps an argument for doing so, particularly as
part of a hard-fork block size increase as more accurate resource
accounting helps prevent many bad-block attacks and let us set
adversarial limits closer to measured capacity in the expected/average
use case. But that would immensely complicate things beyond what could
achieve consensus in a reasonably short amount of time, which is a
goal of this proposal.
Instead I suggest blocking off general recursion by only allowing the
script interpreter to do one tail-call per input. To get log-scaling
benefits without deep recursion we introduce instead one new script
feature, which we'll cover in the next section. But we do leave the
door open to possible future general recursion, as we will note that
going from one layer of recursion to many would itself be a soft-fork
for the same reason that the first tail-call recursion is.
Merkle branch verify to the rescue!
In #bitcoin-wizards and elsewhere there has been a desire for some
time to have an opcode that proves that an item was drawn from the set
used to construct a given Merkle tree. This is not a new idea although
I'm not aware of any actual proposal made for it until now. The most
simple version of the opcode, the version initially proposed, takes
three arguments:
<proof> <leaf-hash> <root-hash> MERKLEBRANCHVERIFY 2DROP DROP
<root-hash> is the 32-byte hash label of the root of the Merkle tree,
calculated using a scheme defined in the fast Merkle hash tree BIP.
<leaf-hash> is 32 bytes of data which we are proving is part of the
Merkle hash tree -- usually the double-SHA256 hash of an item off the
stack.
<proof> is the path through the Merkle tree including the hashes of
branches not taken, which is the information necessary to recalculate
the root hash thereby proving that <leaf-hash> is in the Merkle tree.
The 2DROP and DROP are necessary to remove the 3 arguments from the
stack, as the opcode cannot consume them since it is soft-forked in.
There are two primary motivating applications of Merkle branch verify
(MBV), which will be covered next.
The MBV BIP will be extended to support extraction of more than one
item from the same Merkle tree, but for the rest of this explanation
we assume the current implementation of a single item proof, just for
simplicity.
MBV and MAST
This new opcode combines with single tail-call execution semantics to
allow for a very short and succinct MAST implementation:
OVER HASH256 <root-hash> MERKLEBRANCHVERIFY 2DROP DROP
That's it. This script expects an input stack in the following format:
<argN> ... <arg1> <policyScript> <proof>
At the end of execution the script has verified that <policyScript> is
part of the Merkle tree previously committed to, and <proof> is
dropped from the stack. This leaves the stack ready for a tail-call
recursion into <policyScript>.
MBV and Key Aggregation
If the signature scheme supports key aggregation, which it happens
that the the new signature aggregation scheme being worked on will
support as a side effect, then there is a very cool and useful
application that would be supported as well: tree signatures as
described by Pieter Wuille[1]. This looks almost exactly the same as
the MAST script, but with a CHECKSIG tacked on the end:
OVER HASH256 <root-hash> MERKLEBRANCHVERIFY 2DROP DROP CHECKSIG
This script expects an input stack of the following form:
<sig> <pubkey> <proof>
And proves that the pubkey is drawn from the set used to construct the
Merkle hash tree, and then its signature is checked. While it should
be clear this has 1-of-N semantics, what might be less obvious is that
key aggregation allows any signature policy expressible as a monotone
Boolean function (anything constructible with combinations of AND, OR,
and k-of-N thresholds) to be transformed to a 1-of-N over a set of key
aggregates. So the above script is a generic template able to verify
any monotone Boolean function over combinations of pubkeys, which
encompasses quite a number of use cases!
[1] https://blockstream.com/2015/08/24/treesignatures.html
An argument for permission-less innovation
The driving motivation for the tail-call and MBV proposals, and the
reason they are presented and considered together is to enable
Merklized Abstract Syntax Trees. However neither BIP actually defines
a MAST template, except as an example use case of the primitive
features. This is very much on purpose: it is the opinion of this
author that new bitcoin consensus features should follow the UNIX
philosophy as expressed by Peter Salus and Mike Gancarz and
paraphrased by yours truly:
* Write features that do one thing and do it well.
* Write features to work together.
* Simple is beautiful.
By using modularity and composition of powerful but simple tools like
MERKLEBRANCHVERIFY and single tail-call recursion to construct MAST we
enable a complex and desirable feature while minimizing changes to the
consensus code, review burden, and acquired technical debt.
The reusability of the underlying primitives also means that they can
be combined with other modular features to support use cases other
than vanilla MAST, or reused in series to work around various limits
that might otherwise be imposed on a templated form of MAST. At the
moment the chief utility of these proposals is the straightforward
MAST script written above, but as primitives they do allow a few other
use cases and also combine well with features in the pipeline or on
the drawing board. For example, in addition to MAST you can:
1. Use MERKLEBRANCHVERIFY alone to support honeypot bounties, as
discussed in the BIP.
2. Use a series of MERKLEBRANCHVERIFY opcodes to verify a branch with
split proofs to stay under script and witness push limitations.
3. Combine MERKLEBRANCHVERIFY with key aggregation to get
Wuille-Maxwell tree signatures which support arbitrary signing
policies using a single, aggregatable signature.
4. Combine tail-call execution semantics with CHECKSIGFROMSTACK to get
delegation and signature-time commitment to subscript policy.
5. Combine MERKLEBRANCHVERIFY with a Merkle proof prefix check opcode
and Lamport signature support to get reusable Lamport keys.
I believe these benefits and possible future expansions to be strong
arguments in favor of extending bitcoin in the form of small, modular,
incremental, and reusable changes that can be combined and used even
in ways unforeseen even by their creators, creating a platform for
unrestricted innovation.
The alternative approach of rigid templates achieves the stated goals,
perhaps even with slightly better encoding efficiency, but at the cost
of requiring workaround for each future innovation. P2SH is just such
an example -- we couldn't even upgrade to 128-bit security without
designing an entirely different implementation because of the
limitations of template pattern matching.
Efficiency gains from templating
Finally, I need to point out that there is one efficiency gain that a
proper template-matching implementation has over user-specified
schemes: reduction of witness data. This is both a practical side
effect of more efficient serialization that doesn't need to encode
logic as opcodes, as well as the fact that since the hashing scheme is
fixed, one layer of hashes can be removed from the serialization. In
the case of MAST, rather than encode the Merkle root hash in the
redeem script, the hash is propagated upwards and compared against the
witness commitment. The amount space saved from adopting a template is
about equal to the size of the redeem script, which is approximately
40 bytes of witness data per MAST input.
That is arguably significant enough to matter, and in the long term I
think we will adopt a MAST template for those efficiency gains. But I
feel strongly that since MAST is not a feature in wide use at this
time, it is strongly in our interests to deploy MBV, tail-call, as
well overhaul the CHECKSIG operator before tackling what we feel an
ideal MAST-supporting witness type would look like, so that with some
experience under our belt we can adopt a system that is as simple and
as succinct as possible while supporting the necessary use cases
identified by actual use of the features.
Kind regards,
Mark Friedenbach
_______________________________________________
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/20170920/8a904c22/attachment-0001.html>

2023-06-07 18:01:53

- reply

📅 Original date posted:2017-05-26
📝 Original message:I rarely post here, out of respect to the mailing list. But since my name
was mentioned...
I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only)
with a segwit-like commitment to the coinbase which does not obligate
miners to signal Segwit or implement Segwit, thus disarming any suspicion
that the issue is being exploited only to activate Segwit.
This proposal is unnecessarily conflating two contentious issues and will
attract criticism of self serving motivation.
Politicising CVE is damaging to the long term bitcoin development and to
its security. Not claiming that is the intent here, but the damage is done
by the mere appearance of motive.
On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin-Dev,
>
> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3)
> (4) and actively exploited (5) security vulnerability.
>
> To learn more about this vulnerability please read Jeremy Rubin’s detailed
> report:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> Andreas Antonopoulos has an excellent presentation on why asicboost is
> dangerous:
> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>
> In decisions on the #bitcoin-core-dev IRC channel; It was proposed,
> without negative feedback, that SegWit be used as a partial-mitigation of
> CVE-2017-9230.
>
> SegWit partially mitigates asicboost with the common reasonable assumption
> that any block that doesn’t include a witness commit in it's coinbase
> transaction was mined using covert asicboost. Making the use of covert
> asicboost far more conspicuous.
>
> It was also proposed that this partial mitigation should be quickly
> strengthened via another soft-fork that makes the inclusion of witness
> commits mandatory, without negative feedback.
>
> The security trade-offs of deploying a partial-mitigation to CVE-2017-9230
> quickly vs more slowly but more conservatively is under intense debate.
> The author of this post has a strong preference to the swiftest viable
> option.
>
> Cameron.
>
>
> (1) CVE Entry:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>
> (2) Announcement of CVE to Mailing List:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014416.html
>
> (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan
> Grant:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014352.html
>
> (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier
> Nolan:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014351.html
>
> (5) Evidence of Active Exploit by Gregory Maxwell:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/013996.html
>
> _______________________________________________
> 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/20170526/36b6ccb4/attachment.html>

2023-06-07 17:58:30

- reply

📅 Original date posted:2017-03-29
📝 Original message:I'm requesting feedback and corrections for the second edition of
"Mastering Bitcoin". Apologies if this is considered off-topic - it is only
my second message to this list in 4 years and I think it is relevant
because this book is the first source of information for many new bitcoin
developers.
The book is in pre-production and will be published within the next 6-8
weeks. The new edition covers many new topics including segwit, bip9
signalling, timelocks, payment channels & lightning network. In addition,
most chapters have seen big changes, clarifications and corrections.
The book is open source (CC-BY-SA) and produced on github (
https://github.com/bitcoinbook/bitcoinbook/tree/develop). Pull requests,
issues and comments are welcome, only 2-3 weeks left before it goes into a
production freeze.
Many thanks,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/4e010b11/attachment.html>

2023-06-07 15:09:05

- reply

📅 Original date posted:2013-11-08
📝 Original message:Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317
He dismisses other reasons for delayed block propagation.
Any ideas on whether pools are already mucking around with block delaying
tactics?
I have no idea if this report is accurate or explained by some other issue
in the network, does anyone here have a comment on this?
On Thu, Nov 7, 2013 at 10:28 AM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
>
> Suppose a cabal with fraction q of the total hashing power is n blocks
> ahead on a secret branch of that has mined r_tot coins, and let r_next be
> its next block's reward. If the cabal chooses not to broadcast its secret
> chain until at least the next block, its expected revenue after the next
> block is found is
>
> (1 - (1-q)^(n+1))*(r_tot + r_next)
>
> If it does broadcast, its expected revenue after the next block is found is
>
> r_tot + q * r_next
>
> If the cabal seeks only to maximize immediate revenue, then after a bit of
> algebra we find that it will withhold its chain if
>
> q > 1 - ( 1 + r_tot / r_next )^(-1/n)
>
> So if the cabal has just mined his first block off of the public chain,
> i.e. n = 1, and if the block reward is relatively stable, i.e. r_next =
> r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
> calculated.
>
> From this formula we can also see that if the miner wins the race and
> withholds again, then he must grow q to compensate for the increase in
> r_tot, and any decrease in n. So generally publication becomes
> increasingly in the cabal's interest, and secret chains will tend not to
> grow too large (intuition tells me that simulations using the above formula
> should bear this out).
>
> This seem correct to you?
>
>
> On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> Once the ASIC race calms down because everyone has one, has more or less
>> optimal power supplies, process improvements aren't easily reachable
>> anymore etc then I'd expect people to dissipate from the large pools
>> because eliminating their fees will become the next lowest hanging fruit to
>> squeeze out extra profit. There's no particular reason we need only a
>> handful of pools that control a major fraction of the hashpower.
>>
>> If we end up with a few hundred pools or lots of miners on p2pool, then a
>> lot of these theoretical attacks become not very relevant (I don't think ID
>> sacrifices will be so common or large as to justify a pile of custom mining
>> code+strategies at any point ...)
>>
>>
>> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
>>> > > P.S: If any large pools want to try this stuff out, give me a shout.
>>> You
>>> > > have my PGP key - confidentiality assured.
>>> > >
>>> >
>>> > If I find out one of the large pools decides to run this 'experiment'
>>> on
>>> > the main network, I will make it my mission to tell people to switch
>>> to a
>>> > more responsible pool.
>>>
>>> I hope they listen.
>>>
>>> A few months ago ASICMiner could have made use of that attack if my
>>> memories of their peak hashing power were correct. They certainely could
>>> have used the selfish miner version, (we need better name for that)
>>> although development costs would eat into profits.
>>>
>>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno
>>> what they mean by that, but they're involved with CEX.IO who has
>>> physical control of a bunch of hashing power so I guess that means their
>>> model is like ASICMiners. They're a bit short of 30%, but maybe some
>>> behind-the-scenes deals would fix that, and/or lowering the barrier with
>>> reactive block publishing. (a better name)
>>>
>>> > And if you think you can get away with driving up EVERYBODY's orphan
>>> rate
>>> > without anybody noticing, you should think again.
>>>
>>> ...and remember, if you only do the attack a little bit, you still can
>>> earn more profit, and only drive up the orphan rate a little bit. So who
>>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner
>>> was involved with a bunch of orphans a while back...
>>>
>>> You know what this calls for? A witchhunt!
>>>
>>> BURN THE LARGE POOLS!
>>>
>>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing
>>> > > power, do the math on varience... Seriously, stop it and go mine on a
>>> > > smaller pool, or better yet, p2pool.
>>> > >
>>> >
>>> > That I agree with.
>>>
>>> Glad to hear.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models.
>>> Explore
>>> techniques for threading, error checking, porting, and tuning. Get the
>>> most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131108/ce3a2e5b/attachment.html>

2023-06-07 15:06:44

- reply

📅 Original date posted:2013-09-10
📝 Original message:Excellent!
On Tue, Sep 10, 2013 at 9:44 AM, slush <slush at centrum.cz> wrote:
> Hi all,
>
> we just finalized the draft and reference implementation of BIP39. Regards
> to rules in BIP0001 we're asking for comments.
>
> The aim of the proposal is to standardize algorithm across various clients
> and fix some design problems of existing (but not yet standardized)
> Electrum mnemonic algorithm.
>
> BIP39 is a nice complement to BIP32, which allow users to (paper) backup
> and share their wallet accross multiple clients easily.
>
> Link to BIP: https://en.bitcoin.it/wiki/BIP_0039
>
> Thanks for your time,
> slush
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130910/c2704441/attachment.html>

2023-06-07 15:05:54

- reply

📅 Original date posted:2013-08-11
📝 Original message:Who would be the best person to interview who could explain this issue and
workaround/resolution?
I'd like to get an audio segment for the Let's Talk Bitcoin show ASAP, as
this will be a big concern for many users who will not know what to do or
be able to understand the problem.
Any volunteers for a 15 min audio interview in the next 2 days?
On Sun, Aug 11, 2013 at 9:28 AM, Mike Hearn <mike at plan99.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> I hope you are having a pleasant weekend. A few days ago we learned
> that the Android implementation of the Java SecureRandom class
> contains multiple severe vulnerabilities. As a result all private keys
> generated on Android phones/tablets are weak and some signatures have
> been observed to have colliding R values, allowing the private key to
> be solved and money to be stolen.
>
> The public security alert is here:
>
> http://bitcoin.org/en/alert/2013-08-11-android
>
> I will shortly post in the bitcointalk forums as well.
>
> An update for the Bitcoin Wallet app has been prepared that bypasses
> the system SecureRandom implementation and reads directly from
> /dev/urandom instead, which is believed to be functioning correctly.
> All unspent outputs in the wallet are then respent to this new key.
>
> The process is automatic and does not involve user intervention.
> Andreas can control the process via a percentage throttle, which we
> will use to slow things down if the memory pool load gets too high.
>
> A fixed APK is available here:
>
>
> https://code.google.com/p/bitcoin-wallet/downloads/detail?name=bitcoin-wallet-3.15-beta.apk&can=2&q=
>
> Andreas plans to release this to beta either today or tomorrow. Once
> some reasonable population of users has completed testing the
> automated re-keying process, it will be released via the Play Store.
> All users will get a notification informing them of the new version
> and some will be upgraded automatically.
>
> Other wallet maintainers have also been notified and are working on
> similar updates.
>
> thanks
> - -mike
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJSB7udAAoJEPLkhhyZiIFvv7QIAJQf5AqpNdo0hWSubvcXu6H9
> QoYJllZRb3KhjDEaFU5xinvrN3co6mqRqctbhP2JplrwebEczd8GN4jJZyn90oES
> 7oydQsnYGyO1+W64dnMjOXSCsvIerAv1TuYDIeRmVFlWzXEAbEK3QTB7G/qciF5x
> YNh5M94HYFTCTzDwc3oCHJQUzbl/X/BwPS8TITmEZ3gfYDi+hoyUmHlZukjtFZf+
> /ukDqzWPswscUseuXlUqfu7EMbV0cFO2niCwuTsmkvxkjsz35bPD1LxMYmm1qEjw
> FeKINcws74okK7pnAqsHYIiP0d64zOwfQFJqfFyek18f0LSqYf32h3h1F8GbmJU=
> =bZtl
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130811/8166d4c1/attachment.html>

2023-06-07 15:02:44

- reply

📅 Original date posted:2013-06-06
📝 Original message:> This doesn't work like you might think: first of all, the fees today are
> greatly subsidized - the actual cost to store data in the blockchain is
> much
> higher than most storage solutions. Secondly, only the miner receives the
> fees, not the majority of nodes which have to bear the burden of the data.
> That is, the fee system is setup as an antispam/deterrant, not as payment
> for
> storage.
>
There's a difference between storing the content itself, and storing just a
hash to content (which however is not spendable payment). I undertand why
content itself doesn't belong. But it goes too far to say that only
payments should be allowed.
If the fees are not enough, fix the fee structure, don't stop incredibly
innovative and promising uses of the distributed timestamping database.
That is definitely throwing the baby out with the bathwater. If the issue
is size, then address that, rather than the content itself.
Have I misunderstood this discussion or are some proposing than nothing
except payments be allowed?
Discriminating based on transaction content violates neutrality of the
protocol and in my mind removes a very very large possibility of future
innovation. If bitcoin is a *platform* and not just a payment system, then
it needs to be neutral to content, like TCP/IP so that other protocols can
be layered. Solve the size problem itself, without picking and chosing
which uses of bitcoin are good and which are "bad" or "spam". I think it
risks killing a tremendous amount of innovation just as it is starting.
>
>
>
> Not the same thing at all; nobody is forced to store/relay
> video/voice/images
> without reimbursement. On the other hand, any full Bitcoin node is
> required to
> at least download the entire blockchain once. And the network as a whole
> suffers if nodes decide to start not-storing parts of the blockchain they
> don't want to deal with.
>
> So don't store content, but allow hashes of content.
Again, I think it is extreme and extremely restrictive to say that ONLY
payments are allowed.
> This is how merged mining solves the problem. A single extra hash in the
> coinbase can link the bitcoin blockchain up with unlimited other data.
>
>
>
Can you explain this part or refer me to some docs? What do you mean by
"coinbase", I assume not the company.
Thanks for the reply and explanation!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/bd951646/attachment.html>

2023-06-07 15:02:43

- reply

📅 Original date posted:2013-06-06
📝 Original message:Is there any consideration given to the fact that bitcoin can operate as a
platform for many other services, if it is able to be neutral to payload,
as long as the fee is paid for the transaction size?
Unless I have misunderstood this discussion, it seems to me that this is a
bit like saying in 1990 "IP Is only for email, the majority of users want
email, we shouldn't allow video, voice or images". Ooops, there goes the
web.
Is it possible to solve this by solving the issue of provably un-spendable
outputs without foreclosing on the possibility of other types of
transaction payloads (ie, not money), that would open the possibility for a
myriad of layered apps above? For example, hashes of content that is
external to bitcoin, that people want to pay to have timestamped in the
blockchain, as provably unspendable outputs.
The social compact is to accept transaction for fee. I think it is a major
mistake to make decisions that discriminate on the content of the
transaction, saying that some uses are not appropriate. If the fee is paid
and it covers the size of the transaction, why would it matter if it is not
a payment?
I could be totally misreading this thread, too, so please allow me some
slack if I have!
On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> > scriptPubKey: <data> OP_TRUE
> >
> > ...
> > Along with that change anyone-can-spend outputs should be make
> IsStandard()
> > so they will be relayed.
>
> Data does not belong in the blockchain. People running nodes have all
> implicitly agreed to store the blocks for financial purposes, and storing
> data
> is a violation of that social contract. Proof-of-stake may be arguably
> financial, but I'm sure there must be a way to do it without spamming
> people
> against their consent.
>
> > The alternative is sacrifices to unspendable outputs, which is very
> > undesirable compared to sending the money to miners to further
> > strengthen the security of the network.
>
> The alternative is to make other standard outputs unable to store data as
> well.
>
> Luke
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/89394efb/attachment.html>