<unnamed>

Public Key

npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452

Profile Code

nprofile1qqsfu0rkl4ltsck2xlc4qwgaa0rm4f8cggl250uff3rk5l2rvr0f5qspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc9zhzad

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:13:28 UTC

- reply

📅 Original date posted:2014-02-20
📝 Original message:As I see the BIP it is basically stressing that ver 1 transactions are malleable.
It then addresses the need for unmalleable transactions for e.g. spending unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) - this transaction type is defined as ver 3.
A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as such make an implicit assumption that this is kind of safe, which it is not - it can be intervened and sabotaged through tx malleability.
What I suggested was to ensure that a subclass of version 1 transactions become unmalleable - namely those with sighash=all. Note that only the sender can modify the sighash as it is part of the hash signed. So instead of defining a version 3, we could constrain version 1 txes with sighash=all to have a unmalleable hash. If you e.g. would like to still have a sighash=all type of transaction with malleable features you can simply use that sighash=all today is checked for using sighash&0x1f=sighash_all, so just OR'ing with 0x20 or 0x40 will get you the 'old' feature.
I do however buy the argument of Peter and Gregory that there might exist unpublished transactions out there that does not even conform to the DER rules etc, and as such we cannot forbid them from being mined, nor can we timestamp them and include 'only the old ones'. Hence we cannot change the consensus rule for version 1 transactions - and only changing the relay rules will not provide a certain guarantee.
So, I think the two line argument for the BIP is as follows:
1. We cannot change the consensus rules for version 1 transactions as that might invalidate unpublished non-standard transactions (= voiding peoples money, which is a line we don't want to cross)
2. The prime usecase for unmalleable transactions is being able to spend unconfirmed outputs - this is done today by almost all clients, but it is really broken. Hence a need for a fix asap.
I am all in favor for the BIP, but I expect the realistic timeline for enforced version 3 transactions is roughly one year, which is better than two, but it would have been nice to get it faster...
/M
On Feb 19, 2014, at 10:11 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com> wrote:
>> I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Software should
> deal with malleability. This is a longer-term solution intended to
> provide non-malleability guarantees for clients that a) are upgraded
> to use them b) willing to restrict their functionality. As there are
> several intended use cases for malleable transactions (the sighash
> flags pretty directly are a way to signify what malleabilities are
> *wanted*), this is not about outlawing malleability.
>
> While we could right now make all these rules non-standard, and
> schedule a soft fork in a year or so to make them illegal, it would
> mean removing potential functionality that can only be re-enabled
> through a hard fork. This is significantly harder, so we should think
> about it very well in advance.
>
> About new transaction and block versions: this allows implementing and
> automatically scheduling a softfork without waiting for wallets to
> upgrade. The non-DER signature change was discussed for over two
> years, and implemented almost a year ago, and we still notice wallets
> that don't support it. We can't expect every wallet to be instantly
> modified (what about hardware wallets like the Trezor, for example?
> they may not just be able to be upgraded). Nor is it necessary: if
> your software only spends confirmed change, and tracks all debits
> correctly, there is no need.
>
> --
> Pieter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/d16136fe/attachment.sig>

2023-06-07 15:13:25 UTC

- reply

📅 Original date posted:2014-02-19
📝 Original message:Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly, but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support it.
Rational use cases of #3 will be pretty hard to find given the fact that they can be changed on the fly. We are down to inclusion in blocks by miners for special purposes - or did I miss out something?
I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.
/M
On Feb 19, 2014, at 3:38 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager <gronager at mac.com> wrote:
>> Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:
>>
>> 1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash.
>
> I consider actively mutating other's transactions worse than not
> relaying them. If we want people to make their software deal with
> malleability, either will work.
>
> Regarding deterministic hash: that's impossible. Some signature hash
> types are inherently (and intentionally) malleable. I don't think we
> should pretend to want to change that. The purpose is making
> non-malleability a choice the sender of a transaction can make.
>
> Most of the rules actually are enforced by IsStandard already now.
> Only #1 and #7 aren't. #1 affects the majority of all transactions, so
> changing it right now would be painful. #7 only affects multisig.
>
>> 2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.
>>
>> To non-standard conforming clients this "prettify" change of hash would be seen as a constant malleability attack, but given the "prettify" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.
>>
>> There is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:
>> * Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.
>
> The problem in making these rules into consensus rule (affecting
> tx/block validity) is that some rules (in particular #3) may not be
> wanted by everyone, as they effectively limit the possibilities of the
> script language further. As it is ultimately only about protecting
> senders who care about non-malleability, introducing a new transaction
> version is a very neat way of accomplishing that. The new block
> version number is only there to coordinate the rollout, and choosing
> an automatic forking point.
>
> --
> Pieter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/f91a05d2/attachment.sig>

2023-06-07 15:13:24 UTC

- reply

📅 Original date posted:2014-02-19
📝 Original message:Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:
1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash.
2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.
To non-standard conforming clients this "prettify" change of hash would be seen as a constant malleability attack, but given the "prettify" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.
There is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:
* Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.
On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos at gmail.com> wrote:
>> I apologize if this has been discussed many times before.
>
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>
>> As a long term solution to malleable transactions, wouldn't it be possible
>> to modify the signatures to be of the entire transaction. Why do you have
>> to zero out the inputs? I can see that this would be a hard fork, and maybe
>> it would be somewhat tricky to extract signatures first (since you can sign
>> everything except the signatures), but it would seem to me that this is an
>> important enough change to consider making.
>
> Because doing so would be both unnecessary and ineffective.
>
> Unnecessary because we can very likely eliminate malleability without
> changing what is signed. It will take time, but we have been
> incrementally moving towards that, e.g. v0.8 made many kinds of
> non-canonical encoding non-standard.
>
> Ineffective— at least as you describe it— because the signatures
> _themselves_ are malleable.
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/95dc03a4/attachment.sig>

2023-06-07 15:09:23 UTC

- reply

📅 Original date posted:2013-11-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi John,
Thanks for the feedback - comments below:
>> However, it occurred to me that things can in fact be calculated even
>> simpler: The measured fork rate will mean out all the different pool
>> sizes and network latencies and will as such provide a simple number we
>> can use to estimate the minimum fee.
>
> Are you sure about that? You are assuming linearity where none may exist.
Well, my work from last week and now is a model. A model enabling you to
easily calculate the minimum fee and as a miner which transaction to
include to not shoot yourselves in the foot risking to create an
orphaned block.
The assumption that there is a linearity between block size and latency
is shown pretty well in the paper by Decker et. al (see last weeks
post). What I add this week is mainly more up to date numbers and a
formula dependent only of data that is easy to measure. (fork rate and
block size).
>
> Are those stats accurate? Have any pool operators at least confirmed that the
> orphaned blocks that blockchain.info reports match their own records?
Probably not - but the are at least a minimum - in case they are higher,
the fee should go up further.
>
> My gut feeling is to relay all orphaned blocks. We know that with a high
> investment and sybil attack as blockchain.info has done you can have better
> awareness of orphaned blocks than someone without those resources. If having
> that awareness is ever a profitable thing we have both created an incentive to
> sybil attack the network and we have linked profitability to high up-front
> capital investments.
Another way to measure latency is to setup a node that only listens but
do not relay data. By measuring the propagation of blocks of different
size as well as transactions, you can get a propagation distribution and
from that an average. However, the relevant propagation time is the one
between the pools/(single miners). Which you cannot assess using this
scheme - however, it would be nice to compare it to the orphan block scheme.
>
> With relayed orphans you could even have P2Pool enforce an optimal tx inclusion
> policy based on a statistical model by including proof of those orphans into
> the P2Pool share chain. P2Pool needs to take fees into account soon, but simply
> asking for blocks with the highest total fees or even highest fee/kb appears to
> be incomplete according to what your and Peter's analysis is suggesting.
Indeed, and nice... But note that it is never of benefit for the miner
to include a transaction with a fee of less than ~0.0004BTC - unless it
is linked to another transaction that pay an extra fee.
There have been a lot of assumptions on the fee size and generally it
has been linked to the bitcoin exchange rate. This analysis shows that
this is wrong. Also it shows that the scalability of bitcoin is directly
linked to the network and node latency (with the current latency it will
never beneficial for miners to include more than ~30k transactions in a
block or ~70 pr second resulting in ~10MB blocks).
However, halving the latency will double the capacity, down to the
minimum which is governed by the speed of light.
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSg+H7AAoJEKpww0VFxdGRn+gIAIgju90DED5r//USqKvkQsYI
JDj0tLBLMg9BPXOOt3eJ+NX4YE4lW+QkwqDd/swuJxLmj0l9BQKgt1lTb/f0P/cY
GdE14gh5EYlvNzY1h0TGKcMe8NTWXU0/tC+Clpy4sqBHPXW/eF/77sLQUnFRrLKi
sT48aHOOFUdBLdlyylUzzevh/FFVLidkKqV031tv52+BFHcTFd4kRPwZXgBSs9YH
U66MkJ4ytAqeOfJue9n7Qn4kJF9kNIhRpqTrtapqu8jglLfuYlJ3s5fwaw9FxQdR
+On4IWeXzURQ6tcVRCovCq/2lxRKIbYGlW7HGVASjRmm68/+8YUAfFsYFl6DIgA=
=9tbL
-----END PGP SIGNATURE-----

2023-06-07 15:09:15 UTC

- reply

📅 Original date posted:2013-11-07
📝 Original message:Mike, Pieter,
My writeup outlines a framework for good approximation to a minimal fee
as well as the optimal block size. The model has basically just one
parameter, the propagation time - if that goes down, so can the fee.
(Well there is another parameter too, the time btw blocks, which
currently with the current hash acceleration is more like 400 than 600).
Also seconding Mike, that, yes, it would be tremendously useful to track
propagation times and other things on the network to help us all decide
the proper settings.
Finally, it would be great if someone from academia would grab the ball
and do the full probabilistic analysis based on my outline.
Michael
On 7/11/13, 16:22 , Mike Hearn wrote:
> I think trying to help miners figure out the propagation/fees tradeoff
> at the moment is a non-starter until we understand it better ourselves.
> A server that tracks and records block propagation times, how many fees
> per passed up per block, orphan stats per size bucket etc would be
> tremendously helpful.
>
>
> On Thu, Nov 7, 2013 at 4:19 PM, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
> Correcting myself:
>
> On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
> > I believe that C. Decker's paper used measurements for propagation
> > delays for blocks 180000-190000, which happened between may and juli
> > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
>
> They did use data from blocks 20000-210000, september-november 2012.
> That was still before the 0.8 release, however.
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> 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
> <mailto: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
>

2023-06-07 15:08:38 UTC

- reply

📅 Original date posted:2013-11-04
📝 Original message:"We propose a simple, backwards-compatible change to the Bitcoin
protocol to address this problem and raise the threshold. Specifically,
when a miner learns of competing branches of the same length, it should
propagate all of them, and choose which one to mine on uniformly at random."
So only in the case of two competing chains... The "Selfish Miner" today
has an advantage knowing which chain the other will work on, and by
simply choosing the other they get their advantage making it likely that
it is the other that will waste their effort. By using the random scheme
this advantage is gone.
Note again that it is only in the case of two competing chains, which
will happen on average every 60 blocks. So it is only roughly once every
60 block that you change from choosing one chain to doing a 50% random.
A rough calculation on earnings will be that you loose roughly 1/(2*60)
~ 1% of your blocks using this scheme. But at the same time you make it
harder for such an attack to happen. (This number might be slightly
higher, as working in parallel on both chains will make the two chains
last longer, so agree that we need a bit more analysis...)
I also agree that it is a kind of a Sybil attack, but I think we should
accept the risk of a Sybil attack but of course minimize it, rather than
introducing various social network (ip addresses) solutions, which in
one way or the other always have some central auth / oracle assumption.
On 4/11/13, 13:03 , Mike Hearn wrote:
> The suggested change is actually very simple (minutes of coding) and
> elegant and addresses precisely the identified problem.
>
>
> Disagree. Unless I'm misunderstanding what they propose, their suggested
> change would mean anyone could broadcast a newly discovered block at any
> point and have a 50% chance of being the winner. That is a fundamental
> change to the dynamics of how Bitcoin works that would require careful
> thought and study.
>
> Also, their solution doesn't really address the problem they bring up,
> it just changes the size of the threshold required.
>
> Fundamentally, their attack is a sybil attack. It doesn't work if they
> can't delay or block a pools competitors because mostly their block will
> come in second place and they'll lose the race. Thus the solution should
> be a solution to sybil attacks.

2023-06-07 15:08:37 UTC

- reply

📅 Original date posted:2013-11-04
📝 Original message:On 4/11/13, 12:26 , Mike Hearn wrote:
> W.R.T. this paper and the oft-discussed miner backbone,
>
> http://arxiv.org/pdf/1311.0243v1.pdf
>
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change.
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem. It is actually a
mental shortcut in the assumption of how probability works when mining a
chain. The paper simply corrects this error - nice work!
> Rather than address the
> problem by assuming the network is full of sybil nodes and changing the
> rules for selecting the chain to build on, how about if we wrote code to
> automatically build a miner backbone by having IP addresses of nodes
> embedded into coinbases, then having any bitcoind that is creating work
> automatically connect to IPs that appeared in enough recent blocks?
You suggestion could perhaps be fun for other purposes, but does not
rule out pools of "selfish miners". Further, it binds physical state
(ip) to the blockchain, which has so far held no assumptions on the
technology of the system on which it is running.
>
> This would have the effect of automatically linking all the major pools
> together, with no administration overhead.
>
> For bonus points, the IPs could be IPv6 and then the trick we use to
> pack hidden services into IPv6 address space would allow nodes to be
> reached via Tor. This might be useful in the case of pools that don't to
> reveal the location of their bitcoin node[s], like for anti-DoS reasons.
>
> It feels like this should be achievable with a few days of solid coding
> and a couple of new command line flags, and the impact is much easier to
> reason about than a fundamental rule change like the one proposed by the
> paper.
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:04:56 UTC

- reply

📅 Original date posted:2013-07-23
📝 Original message:>
> The only way to do this safely at an SPV security assumption, is by
> having an address-indexed committed merkle UTXO-set tree, like the
> one proposed by Alan Reiner, and being implemented by Mark
> Friedenback. I know Michael Gronager has something similar implemented,
> but I don't know whether it is script-indexed.
The MerkleTrie I have in libcoin is indexed on UTXOs only. However, adding
an extra index for scripts would be pretty easy (half day of coding), or even having the two merged into one index.
The burden imposed on validating nodes for keeping such an index is really minimal. When using the UTXO MerkleTrie I switch off the sqlite index of these and vise versa, so there are hardly any measurable timing difference.
However, the MerkleTrie index is currently re-build on startup (which takes ~30 sec on my laptop), keeping it synced with disk would be optimal and in the long run necessary as even the UTXO set will grow over time.
> To be actually useful,
> it likely needs to be enforced by miners - putting a significant
> burden on validation nodes. Still, if it can be done efficiently,
> I think this would be worth it, but more research is needed first in
> any case.
>

2023-06-07 15:04:55 UTC

- reply

📅 Original date posted:2013-07-23
📝 Original message:Hi Andreas / Jeff,
Access to the UTXO set can be done using libcoin (see the coinexplorer example), which also has a rest interface. Access to the UTXO set pr address/script requires indexing of all scripts, which was easy in libcoin as the blockchain is stored in a sqlite database. Integrating this in bitcoind would require setting up and maintaining such an index ad hoc.
Michael
On Jul 23, 2013, at 10:27 , Andreas Schildbach <andreas at schildbach.de> wrote:
> On 07/22/2013 09:42 PM, Jeff Garzik wrote:
>
>> The general goal of the HTTP REST interface is to access
>> unauthenticated, public blockchain information. There is no plan to
>> add wallet interfacing/manipulation via this API.
>
> Is it planned to expose the UXTO set of a given address? That would be
> useful for SPV wallets to be able to swipe a previously unknown private
> key (e.g. paper wallet).
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:04:46 UTC

- reply

📅 Original date posted:2013-07-17
📝 Original message:> Is that still accurate Michael?
>
The 90 minutes is not - the blockchain has grown quite a lot since last year, and as for the 3.5 speed, I havn't tested it since Pieter's ultraprune - libcoin also has something similar to ultraprune, done directly in the sqlite database backend, but I should run a head to head again - could be fun. I would assume, though, that the result would be similar timings.
However, by having a merkle tree hash of all UTXOs they become downloadable in a trusted manner from any other client - something that enables bootstrap in minutes, so the old numbers becomes less relevant in this setting.
>
> On Wed, Jul 17, 2013 at 4:58 PM, Wendell <w at grabhive.com> wrote:
> "The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!"
>
>

2023-06-07 15:04:45 UTC

- reply

📅 Original date posted:2013-07-17
📝 Original message:Hi Wendell,
What Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with "master".
Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.
What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)
Michael
On 17/07/2013, at 09:37, Wendell <w at grabhive.com> wrote:
> Peter,
>
> This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.
>
> Will you implement this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive
>
> On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:
>
>> So what's useful about that? Basically it means your node starts with
>> the same security level, and usefulness to the network, as a SPV node.
>> But over time you keep downloading blocks as they are created, and with
>> whatever bandwidth you have left (out of some user-configurable
>> allocation) you download additional blocks going further and further
>> back in time. Gradually your UTXO set becomes more complete, and over
>> time you can verify a higher and higher % of all valid transactions.
>> Eventually your node becomes a full node, but in the meantime it was
>> still useful for the user, and still contributed to the network by
>> relaying blocks and an increasingly large subset of all transactions.
>> (optionally you can store a subset of the chain history too for other
>> nodes to bootstrap from) You've also got better security because you
>> *are* validating blocks, starting off incompletely, and increasingly
>> completely until your finally validating fully. Privacy is improved, for
>> both you and others, by mixing your transactions with others and adding
>> to the overall anonymity set.
>>
>> In the future we'll have miners commit a hash of the UTXO set, and that
>> gives us even more options to, for instance, have relayed transactions
>> include proof that their inputs were valid, allowing all nodes to relay
>> them safely.
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/d6c0fe64/attachment.sig>

2023-06-07 15:02:29 UTC

- reply

📅 Original date posted:2013-05-27
📝 Original message:Commenting on my own mail...
Rereading the BIP, it occurs to me that the private derivation is
actually intentional. So:
(m/i/j/k)*G = (M/i/j/k), but (m/i'/j/k)*G <> (M/i/j/k) (M/i'/j/k => ERROR)
But: ((m/i')*G)/j/k = (m/i'/j/k)*G
So, the motivation for the private derivation is to avoid the known (K,
c) and known k_i => k known too! I fear that many will fall in this
trap, though...
/Michael

2023-06-07 11:37:15 UTC

- reply

📅 Original date posted:2013-03-12
📝 Original message:Well a reversed upgrade is an upgrade that went wrong ;)
Anyway, the incident makes it even more important for people to upgrade, well except, perhaps, for miners...
Forks are caused by rejection criteria, hence:
1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_.
2. If you loosen some rejection criteria miners should upgrade _last_.
3. If you keep the same criteria assume 2.
/M
On 12/03/2013, at 13:11, Mike Hearn <mike at plan99.net> wrote:
> I'm not even sure I'd say the upgrade "went wrong". The problem if
> anything is the upgrade didn't happen fast enough. If we had run out
> of block space a few months from now, or if miners/merchants/exchanges
> had upgraded faster, it'd have made more sense to just roll forward
> and tolerate the loss of the older clients.
>
> This really reinforces the importance of keeping nodes up to date.
>
> On Tue, Mar 12, 2013 at 12:44 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>> On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
>>> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and unknown criteria for block rejection, hence the upgrade went wrong.
>>
>> We're using "0.7" as a short moniker for all clients, but this was a limitation that all
>> BDB-based bitcoins ever had. The bug is simply a limit in the number of lock objects
>> that was reached.
>>
>> It's ironic that 0.8 was supposed to solve all problems we had due to BDB (except the
>> wallet...), but now it seems it's still coming back to haunt us. I really hated telling
>> miners to go back to 0.7, given all efforts to make 0.8 signficantly more tolerable...
>>
>>> More space in the block is needed indeed, but the real problem you are describing is actually not missing space in the block, but proper handling of mem-pool transactions. They should be pruned on two criteria:
>>>
>>> 1. if they gets to old >24hr
>>> 2. if the client is running out of space, then the oldest should probably be pruned
>>>
>>> clients are anyway keeping, and re-relaying, their own transactions and hence it would mean only little, and only little for clients. Dropping free / old transaction is a much a better behavior than dying... Even a scheme where the client dropped all or random mempool txes would be a tolerable way of handling things (dropping all is similar to a restart, except for no user intervention).
>>
>> Right now, mempools are relatively small in memory usage, but with small block sizes,
>> it indeed risks going up. In 0.8, conflicting (=double spending) transactions in the
>> chain cause clearing the mempool of conflicts, so at least the mempool is bounded by
>> the size of the UTXO subset being spent. Dropping transactions from the memory pool
>> when they run out of space seems a correct solution. I'm less convinced about a
>> deterministic time-based rule, as that creates a double spending incentive at that
>> time, and a counter incentive to spam the network with your risking-to-be-cleared
>> transaction as well.
>>
>> Regarding the block space, we've seen the pct% of one single block chain space consumer
>> grow simultaneously with the introduction of larger blocks, so I'm not actually convinced
>> there is right now a big need for larger blocks (note: right now). The competition for
>> block chain space is mostly an issue for client software which doesn't deal correctly
>> with non-confirming transactions, and misleading users. It's mostly a usability problem
>> now, but increasing block sizes isn't guaranteed to fix that; it may just make more
>> space for spam.
>>
>> However, the presence of this bug, and the fact that a full solution is available (0.8),
>> probably helps achieving consensus fixing it (=a hardfork) is needed, and we should take
>> advantage of that. But please, let's not rush things...
>>
>> --
>> Piter
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:44:33 UTC

- reply

📅 Original date posted:2012-12-03
📝 Original message:> If this were a proposal at the time Bitcoin was created, I would definitely be in favor, but I feel we can't just change such a policy right now - it's not what people signed up for when they started using the system. I also see no way to implement this without a hard fork, which would require planning at least 1-2 years in advance (imho). By that time, the economic landscape of Bitcoin may be vastly different, and either dust spam will have killed it, or we will have found another solution already.
Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will likely be accepted quite fast - especially now when the bounty was just halved... I also fear that there is a lot of BTCs that is effectively un-owned and it could even drive Satoshi to use some of his BTCs ;)
> Personally, I think the best solution is to change the mining policy to prioritize (and perhaps favor for free relay/inclusion) transactions that reduce the number of UTXO's.
Agree - initially (and possibly in parallel) this would be a nice path to follow - it could be done solely by adjusting the relay fee: Transactions that increases the # UTXOs pay extra, those that reduce it pay less (symmetrical around a minimum fee). So in other words we 'tax' increasing the size of the UTXOs.
No matter how it is done - as long as a client is not punished for getting rid of dust, and clients are rewritten to do this automatically we could re-evaluate after a some time - but currently the number of UTXOs is growing rapidly.
/M
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel projects.
> http://goparallel.sourceforge.net_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:44:26 UTC

- reply

📅 Original date posted:2012-12-03
📝 Original message:(Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0)
The amount of "dust" in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.00000001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!)
This means that a huge part of the block chain is used for essentially nothing - e.g. the sum of the 11% is worth roughly 2 US cents !
The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing wrong with that, however, we should work on ensuring that too many too small payments will not kill the size of the blockchain in the end - further, they are essentially too small to be included in other transaction as the added fee will often make it more expensive to remove them. Hence, there is no incentive to get rid of them.
I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see:http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging:
1-99 Satoshi: lives for 210 blocks
100-9999 Satoshi: lives for 2100 blocks
10000-999999 Satoshi: lives for 21000 blocks
1000000-99999999 Satoshi: lives for 210000 blocks
Only amounts above 1BTC lives forever - (or we could even impose aging on those too..)
The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever.
This scheme will impose some lifetimes also on e.g. colored coins (hence you need to use a certain amount to borrow space on the blockchain for the time needed, or simply transact them).
If you like this I would be happy to write it into a BIP.
Thoughts ?

2023-06-07 10:41:07 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:> No, the point of using X509 certs is to get a verified identity (a
> domain name) on the receipt, this is needed for multi-factor
> authentication. You can't do that without some kind of third party
> asserting to an identity.
Agree that you need a third party to verify identity. But the verification policy of sites is the job for a payment provider not a payment technology. So if you would like verification of the site you could just sign the memo using standard S/MIME - why mix it with the payment protocol?
Further, it is controversial use of the host key to use it for digital signing of documents, and not even within the policy of a host certificate as far as I recall.
The problem you are trying to tackle is that we don't have an ID solution on the internet today for this purpose. Certificates for signing messages are distributed freely and insecurely only based on temporarily having an email from within an organization, and the host certificates are meant for SSL handshakes. Funnily, any CA can issue digital certificates for email signing for any domain, even though they don't own them, and without notifying the owner. DANE actually solves this, but until then using the host certificates is unintended use, it is cryptographically a nice solution, but legally and standard-wise a hack.
/M

2023-06-07 10:41:00 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:>
> If a merchant/payment processor is willing to take the risk of zero or
> low confirmation transactions (because they are insured against it,
> for example), they were allowed to reply "accepted" immediately, and
> this would be a permanent proof of payment, even if the actual Bitcoin
> transaction that backs it gets reverted.
I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn't get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...)
So the SignedReceipt is legally not worth the bits it is composed of, hence I don't see the point in supporting it.
If you are selling atoms you can usually wait for N confirmations (even though you start shipping I guess you can recall a parcel within 144 blocks). If you are selling bits (like access to a site), you can revoke that access once you discover the transaction did not go through. So I can't find a use case where a Signed Receipt in the proposed form is advantageous.
/M

2023-06-07 10:40:54 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:>
> The SignedReceipt message is useful in the sense that it shows
> confirmation by the merchant, but if you don't get one, you can still
> prove you paid the invoice. So from this perspective perhaps
> SignedReceipt should be renamed to Acceptance or something like that,
> and then the spec should call out that a signed invoice plus accepted
> Bitcoin transactions is mathematically a proof of purchase.
Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway.
Further, the inclusion of x509 is not really needed in the spec - you don't need to sign the invoice with an x509, you can use the payment key. The proof would still be equally binding, and valid also for non holders of x509 (server) certificates (like normal people).
Finally, host certificates does not normally keep in their "purpose" S/MIME Signing. So you are bending the intended use of the x509 certificate anyway.
/M
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:40:48 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:Short comments:
* What if the SignedReceipt is not received AND the transactions IS posted on the p2p. Then you have payed for the goods, but you don't have a receipt. This could happen both from malice or system failures.
** Suggestion - sign the invoice with the key to which to send the transaction, the proof of payment, equivalent to a signed receipt is then in the blockchain.
This scheme would work both with or without x509, if you want to include x509, the message in the invoice could simply be signed by the x509 certificate as well.
PRO: Any user can send signed invoices, not only those with a x509 cert.
PRO: No limbo situation with no SignedReceipt
CON: This disables the use of anything but payment to key/address incl multisig etc.
However, the wast majority of use will anyway be payment to key/address.
Support of general pay to script could be supported through the payment scheme proposed earlier by Mike: No non-fee payments are accepted, except in a group - i.e. it is up to the merchant to generate the final transaction incl the fees, and that one could be to a general script. This also keeps the support of pay to general script needed for a client to a minimum.
Cheers,
Michael