Alan Reiner [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-10-25 to 2015-05-08
💬 Posted a total of 135 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP proposal, ANN, BIP draft
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h

Profile Code

nprofile1qqsgdaptedm2gvwp9z6edsm8zjh88fpv4ey8q65725faw9syx3rltmqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc84cr0

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h

Show more details

Last Notes

2023-06-07 17:33:21

- reply

📅 Original date posted:2015-05-08
📝 Original message:Actually I believe that side chains and off-main-chain transactions will be
a critical part for the overall scalability of the network. I was actually
trying to make the point that (insert some huge block size here) will be
needed to even accommodate the reduced traffic.
I believe that it is definitely over 20MB. If it was determined to be 100
MB ten years from now, that wouldn't surprise me.
Sent from my overpriced smartphone
On May 8, 2015 1:17 PM, "Andrew" <onelineproof at gmail.com> wrote:
>
>
> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>
>>
>> This isn't about "everyone's coffee". This is about an absolute minimum
>> amount of participation by people who wish to use the network. If our
>> goal is really for bitcoin to really be a global, open transaction network
>> that makes money fluid, then 7tps is already a failure. If even 5% of the
>> world (350M people) was using the network for 1 tx per month (perhaps to
>> open payment channels, or shift money between side chains), we'll be above
>> 100 tps. And that doesn't include all the non-individuals (organizations)
>> that want to use it.
>>
>
>> The goals of "a global transaction network" and "everyone must be able to
>> run a full node with their $200 dell laptop" are not compatible. We need
>> to accept that a global transaction system cannot be fully/constantly
>> audited by everyone and their mother. The important feature of the network
>> is that it is open and anyone *can* get the history and verify it. But not
>> everyone is required to. Trying to promote a system wher000e the history
>> can be forever handled by a low-end PC is already falling out of reach,
>> even with our miniscule 7 tps. Clinging to that goal needlessly limits the
>> capability for the network to scale to be a useful global payments system
>>
>
> These are good points and got me thinking (but I think you're wrong). If
> we really want each of the 10 billion people soon using bitcoin once per
> month, that will require 500MB blocks. That's about 2 TB per month. And if
> you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
> for a home desktop, so you can just run a pruned full node with all
> transactions from the past month. But how do you sync all those
> transactions if you've never done this before or it's been a while since
> you did? I think it currently takes at least 3 hours to fully sync 30 GB of
> transactions. So 2 TB will take 8 days, then you take a bit more time to
> sync the days that passed while you were syncing. So that's doable, but at
> a certain point, like 10 TB per month (still only 5 transactions per month
> per person), you will need 41 days to sync that month, so you will never
> catch up. So I think in order to keep the very important property of anyone
> being able to start clean and verify the thing, then we need to think of
> bitcoin as a system that does transactions for a large number of users at
> once in one transaction, and not a system where each person will make a
> ~monthly transaction on. We need to therefore rely on sidechains,
> treechains, lightning channels, etc...
>
> I'm not a bitcoin wizard and this is just my second post on this mailing
> list, so I may be missing something. So please someone, correct me if I'm
> wrong.
>
>>
>>
>>
>> On 05/07/2015 03:54 PM, Jeff Garzik wrote:
>>
>> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>>
>>
>>> (2) Leveraging fee pressure at 1MB to solve the problem is actually
>>> really a bad idea. It's really bad while Bitcoin is still growing, and
>>> relying on fee pressure at 1 MB severely impacts attractiveness and
>>> adoption potential of Bitcoin (due to high fees and unreliability). But
>>> more importantly, it ignores the fact that for a 7 tps is pathetic for a
>>> global transaction system. It is a couple orders of magnitude too low for
>>> any meaningful commercial activity to occur. If we continue with a cap of
>>> 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be
>>> useful for the vast majority of the world (which probably leads to
>>> failure). We shouldn't be talking about fee pressure until we hit 700 tps,
>>> which is probably still too low.
>>>
>> [...]
>>
>> 1) Agree that 7 tps is too low
>>
>> 2) Where do you want to go? Should bitcoin scale up to handle all the
>> world's coffees?
>>
>> This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day --
>> just for a single feed. If you include relaying to multiple nodes, plus
>> serving 500 million SPV clients en grosse, who has the capacity to run such
>> a node? By the time we get to fee pressure, in your scenario, our network
>> node count is tiny and highly centralized.
>>
>> 3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
>> system? It is an intentional, human decision to flood the market with
>> supply, thereby altering the economics, forcing fees to remain low in the
>> hopes of achieving adoption. I'm pro-bitcoin and obviously want to see
>> bitcoin adoption - but I don't want to sacrifice every decentralized
>> principle and become a central banker in order to get there.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/4f232d91/attachment.html>

2023-06-07 17:33:19

- reply

📅 Original date posted:2015-05-08
📝 Original message:This isn't about "everyone's coffee". This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure. If even
5% of the world (350M people) was using the network for 1 tx per month
(perhaps to open payment channels, or shift money between side chains),
we'll be above 100 tps. And that doesn't include all the
non-individuals (organizations) that want to use it.
The goals of "a global transaction network" and "everyone must be able
to run a full node with their $200 dell laptop" are not compatible. We
need to accept that a global transaction system cannot be
fully/constantly audited by everyone and their mother. The important
feature of the network is that it is open and anyone *can* get the
history and verify it. But not everyone is required to. Trying to
promote a system where the history can be forever handled by a low-end
PC is already falling out of reach, even with our miniscule 7 tps.
Clinging to that goal needlessly limits the capability for the network
to scale to be a useful global payments system
On 05/07/2015 03:54 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>
> (2) Leveraging fee pressure at 1MB to solve the problem is
> actually really a bad idea. It's really bad while Bitcoin is
> still growing, and relying on fee pressure at 1 MB severely
> impacts attractiveness and adoption potential of Bitcoin (due to
> high fees and unreliability). But more importantly, it ignores
> the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any
> meaningful commercial activity to occur. If we continue with a
> cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will
> fail to be useful for the vast majority of the world (which
> probably leads to failure). We shouldn't be talking about fee
> pressure until we hit 700 tps, which is probably still too low.
>
> [...]
>
> 1) Agree that 7 tps is too low
>
> 2) Where do you want to go? Should bitcoin scale up to handle all the
> world's coffees?
>
> This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day --
> just for a single feed. If you include relaying to multiple nodes,
> plus serving 500 million SPV clients en grosse, who has the capacity
> to run such a node? By the time we get to fee pressure, in your
> scenario, our network node count is tiny and highly centralized.
>
> 3) In RE "fee pressure" -- Do you see the moral hazard to a
> software-run system? It is an intentional, human decision to flood
> the market with supply, thereby altering the economics, forcing fees
> to remain low in the hopes of achieving adoption. I'm pro-bitcoin and
> obviously want to see bitcoin adoption - but I don't want to sacrifice
> every decentralized principle and become a central banker in order to
> get there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/aa6f7b9a/attachment.html>

2023-06-07 17:33:19

- reply

📅 Original date posted:2015-05-08
📝 Original message:On 05/08/2015 01:13 AM, Tom Harding wrote:
> On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>> G proposed 20MB blocks, AFAIK - 140 tps
>> A proposed 100MB blocks - 700 tps
>> For ref,
>> Paypal is around 115 tps
>> VISA is around 2000 tps (perhaps 4000 tps peak)
>>
For reference, I'm not "proposing" 100 MB blocks right now. I was
simply suggesting that if Bitcoin is to *ultimately* achieve the goal of
being a globally useful payment rails, 7tps is embarrassingly small.
Even with off-chain transactions. It should be a no-brainer that block
size has to go up.
My goal was to bring some long-term perspective into the discussion. I
don't know if 100 MB blocks will *actually* be necessary for Bitcoin in
20 years, but it's feasible that it will be. It's an open, global
payments system. Therefore, we shouldn't be arguing about whether 1 MB
blocks is sufficient--it's very clearly not. And admitting this as a
valid point is also an admission that not everyone in the world will be
able to run a full node in 20 years.
I don't think there's a solution that can accommodate all future
scenarios, nor that we can even find a solution right now that avoids
more hard forks in the future. But the goal of "everyone should be
able to download and verify the world's global transactions on a
smartphone" is a non-starter and should not drive decisions.

2023-06-07 17:33:17

- reply

📅 Original date posted:2015-05-07
📝 Original message:This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> 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/20150507/8d08315a/attachment.html>

2023-06-07 17:30:15

- reply

📅 Original date posted:2015-02-12
📝 Original message:I'll add fuel to the fire here, and express that I believe that
replace-by-fee is good in the long-term. Peter is not breaking the
zero-conf, it was already broken, and not admitting it creates a false
sense of security. I don't want to see systems that are built on the
assumption that zero-conf tx are safe solely because it has always
appeared safe. You can argue about rational miner behaviors all day,
but in a decentralized system you have no idea what miners consider
rational, or speculate about their incentives.
If there's one thing I learned playing poker (many years ago), was that
always assuming your opponent is rational can lose you a lot of money.
You made play that, in hindsight, was terrible given what he actually
had. But you assumed no sane or rational person in his position would
make such a play so you discounted it in your decision-making process.
You're "right" that his actions were terrible and irrational, but he
still won your money because you discounted his ability to make such a
"bad" play. Here, you are speculating that an "opponent" uses the same
values/motivations/rationality as yourself, and then building systems
that depend on that being true. Even if it "should" be true doesn't
mean that it is true and will remain that way. And you will get burned
by it eventually.
The Bitcoin network achieves something that we didnt' think was possible
10 years ago: a totally trustless, decentralized ledger. The cost? It
takes time for the decentralized network to reach consensus that
transactions "happened". That is quite literally the trade-off that we
make: you can centralize things by putting a bank in the middle and
getting instant confirmation, or you decentralize and let the network
reach consensus over time without the central authority. If you want
instant confirmations, you're going to need to add centralization
because Bitcoin never offered it. I support efforts to dispel any such
myths as soon as possible and encourage building robust solutions
(payment channels, insured zero-conf services, etc.).
-Alan
On 02/12/2015 07:37 PM, Allen Piscitello wrote:
> You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It
does, and there are incentives to use it by miners. These are the
bounds we have to deal with and the world we must adapt to.
>
> On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
<justusranvier at riseup.net <mailto:justusranvier at riseup.net>> wrote:
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
> >> 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.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
>
>
------------------------------------------------------------------------------
> 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/
> _______________________________________________
> 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
>
>
>
>
>
------------------------------------------------------------------------------
> 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/
>
>
> _______________________________________________
> 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/20150212/f851bd85/attachment.html>

2023-06-07 17:29:05

- reply

📅 Original date posted:2015-01-23
📝 Original message:On 01/23/2015 11:27 AM, Alan Reiner wrote:
>
> I am happy to entertain other ideas that achieve our goals here, but I'm
> fairly confident that the new SIGHASH type is the only way that would
> allow devices like Trezor to truly simplify their design (and still work
> securely on 100% of funds contained by the wallet).
>
Self-correction ... I didn't mean it's the "only way", I mean it's by
far the easiest, simplest, least-intrusive way that achieves the
properties we need for this to be useful.

2023-06-07 17:29:05

- reply

📅 Original date posted:2015-01-23
📝 Original message:On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties. Most of the
>> soft-fork variations of it required the coins being spent to have been
>> originated in a special way. In other words, it would only work if the
>> coins had entered the wallet with some special, modified TxOut script. So
>> it wouldn't work with existing coins, and would require senders to update
>> their software to reshape the way they send transactions to be compatible
>> with our goals.
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new signature type... but thats
> only the case for people who want the new capability. This is
> massively preferable to expecting _every_ _other_ user of the system
> (including miners, full nodes, etc.) to replace their software with an
> incompatible new version just to accommodate your transactions, for
> which they may care nothing about and which would otherwise not have
> any urgent need to change.
>
>
As far as I'm concerned, anything that requires the coins to originate
in the wallet with some special form is a non-starter. The new SIGHASH
type allows you to sign transactions with *any* coins already in your
wallet, and imposes no requirements on anyone paying your cold wallet to
be compatible with your signer.
Any proposals that require coin origination features means that 100% of
people paying you need to "be nice" and send you coins with this special
structure. You can't spend old coins that were sent before this
proposal was implemented, and if anyone sends you coins without
respecting the new structure, then your signing devices need the
full-complexity routines to accommodate, which defeats the entire purpose.
I am happy to entertain other ideas that achieve our goals here, but I'm
fairly confident that the new SIGHASH type is the only way that would
allow devices like Trezor to truly simplify their design (and still work
securely on 100% of funds contained by the wallet).

2023-06-07 17:29:04

- reply

📅 Original date posted:2015-01-23
📝 Original message:On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties. Most of the
>> soft-fork variations of it required the coins being spent to have been
>> originated in a special way. In other words, it would only work if the
>> coins had entered the wallet with some special, modified TxOut script. So
>> it wouldn't work with existing coins, and would require senders to update
>> their software to reshape the way they send transactions to be compatible
>> with our goals.
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new signature type... but thats
> only the case for people who want the new capability. This is
> massively preferable to expecting _every_ _other_ user of the system
> (including miners, full nodes, etc.) to replace their software with an
> incompatible new version just to accommodate your transactions, for
> which they may care nothing about and which would otherwise not have
> any urgent need to change.
>
>
As far as I'm concerned, anything that requires the coins to originate
in the wallet with some special form is a non-starter. The new SIGHASH
type allows you to sign transactions with any coins already in your
wallet, and imposes no requirements on anyone paying your cold wallet.
Any such proposals that require origination structure means that 100% of
people paying you need to "be nice" and use this new script type, or
else you *have* to

2023-06-07 17:29:02

- reply

📅 Original date posted:2015-01-23
📝 Original message:The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it if
they don't want to upgrade their signers. The proposal simply provides
a way to optionally sign the input values with the TxOut scripts. In
other words a signature right now says "I sign this transaction using
these inputs, whatever value they are." With this SIGHASH type, the
signature says "I sign this transaction assuming that input 0 is X BTC,
input 1 is Y BTC,....". If the online computer providing the data to be
signed lies about the value of any input, the resulting signature will
be invalid.
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations of it required the coins being spent to have been
originated in a special way. In other words, it would only work if the
coins had entered the wallet with some special, modified TxOut script.
So it wouldn't work with existing coins, and would require senders to
update their software to reshape the way they send transactions to be
compatible with our goals.
I *strongly* encourage this to be considered for inclusion at some
point. Not only does it simplify HW as Marek suggested, it increases
the options for online-offline communication channels, which is also a
win for security. Right now, QR codes don't work because of the
possibility of having to transfer megabytes over the channel, and no way
to for the signer to control that size. With this change, it's possible
for the signer to control the size of each chunk of data to guarantee it
fits in, say, a QR code (even if it means breaking it up into a couple
smaller transactions).
-Alan
On 01/23/2015 09:51 AM, slush wrote:
> Hi,
>
> is any progress or even discussion in this area?
>
> https://bitcointalk.org/index.php?topic=181734.0
>
> I don't insist on any specific solution, but this is becoming a real
> issue as hardware wallets are more widespread. I'm sitting next to
> TREZOR for 40 minutes already, because it streams and validate some
> complex transaction. By using proposed solution, such signature would
> be a matter of few seconds.
>
> That's also not just about time/resource/hw cost optimization. I'm
> talking about possibility of huge simplification of the firmware
> (=security FTW), because 50% of actual codebase is solving this
> particular downside of Bitcoin protocol.
>
> So, there's real world problem. On which solution can we as a
> community find a wide agreement?
>
> Best,
> Marek
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> 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/20150123/46e022bd/attachment.html>

2023-06-07 17:28:36

- reply

📅 Original date posted:2015-01-19
📝 Original message:I'm a bit confused. It's been a long time since I looked at protobuf
(and will have to dig into it soon), but I seem to recall it doesn't
have any of the determinism properties you guys just said. It is
intended to allow you to skip details of the on-the-wire representations
and just send a bunch of named fields between systems. I thought there
was no guarantee that two identical protobuf structures will get
serialized identically...?
On 01/19/2015 02:57 PM, Richard Brady wrote:
> Thanks guys, great answers.
>
> The design choice certainly makes a lot more sense now regardless of
> whether one agrees with it or not.
>
> Regards,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> 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/20150119/c6c82c2c/attachment.html>

2023-06-07 17:28:33

- reply

📅 Original date posted:2015-01-16
📝 Original message:I see no reason to restrict compressed/uncompressed. Strings don't have
to be the same length to sort them lexicographically. If a multi-sig
participant provides an uncompressed key, they are declaring that the
key that they use and it will only be used uncompressed. Clients don't
have to go looking for all combinations of compressed & uncompressed.
On 01/16/2015 11:34 AM, Thomas Kerin wrote:
>
>
> It seems there is scope for further narrowing down how a multisig
> scripthash address should be determined - what do people think of
> anticipating only compressed keys for scripts?
>
> It's possible to cause confusion if one put forward a compressed key
> at some time, and an uncompressed key at another. A different script
> hash would be produced even though there is no difference to the keys
> involved. The client will not search for this.
>
>
> Having spoken with Jean-Pierre and Ruben about this for quite some
> time now, there is 100% the need for a BIP outlining this. Everyone
> has had the idea at some point, and some of us already using it, but
> people shouldn't have to go digging in BIP45 for the two lines which
> mention it. All we need is a place to put the docs.
>
> I am building up a list of implementations which currently support
> sorting, and briefly describing a motivation for such a BIP.
>
>
> On 16/01/15 10:16, Ruben de Vries wrote:
> > Since we only need the sorting for creating the scriptPubKey,
> > wouldn't it make the most sense to sort it by the way it represented
> in that context?
>
>
> > On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj at gmail.com
> <mailto:laanwj at gmail.com>> wrote:
>
> > On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
> <bip at mattwhitlock.name <mailto:bip at mattwhitlock.name>> wrote:
> > > On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
> > >> Internally, pubkeys are DER-encoded integers.
> > >
> > > I thought pubkeys were represented as raw integers (i.e.,
> they're embedded in Script as a push operation whose payload is the
> raw bytes of the big-endian representation of the integer). As far as
> I know, DER encoding is only used for signatures. Am I mistaken?
>
> > OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
> > DER-encoded signature on the stack.
>
> > Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
> > used in outputs, which compares the 160-bit hash of the pubkey
> against
> > the given hash (usually taken from a bitcoin address).
>
> > It doesn't help understanding to consider either as integers.
> They are
> > binary blob objects with either a fixed format (DER) or a fixed size
> > (hashes).
>
> > Wladimir
>
>
>
>
> > --
> > BlockTrail B.V.
> > Barbara Strozzilaan 201
> > 1083HN Amsterdam
> > The Netherlands
>
> > Phone:+31 (0)612227277
> > E-mail:ruben at blocktrail.com <mailto:ruben at blocktrail.com>
> > Web:www.blocktrail.com
> > <http://www.blocktrail.com/>
> > Github:www.github.com/rubensayshi <http://www.github.com/rubensayshi>
>
> > BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
> Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
>
>
> >
> ------------------------------------------------------------------------------
> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> > GigeNET is offering a free month of service with a new server in
> Ashburn.
> > Choose from 2 high performing configs, both with 100TB of bandwidth.
> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> > http://p.sf.net/sfu/gigenet
>
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> 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/20150116/74819d20/attachment.html>

2023-06-07 17:25:52

- reply

📅 Original date posted:2014-09-23
📝 Original message:This topic has been touched on briefly here before, but I wanted to
solidify it and propose it as a BIP if there is wider support for it.
Also, the topic is difficult to discuss without lots of pictures -- so
that's what I've done (mainly to describe it to my team, but also as
general documentation). It's in presentation form:
https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf
The proposal is that for an M-of-N multisig wallet based on BIP32, there
should be N internal chains and N external chains. Each party is
assigned a chain based on the lexicographic ordering of their wallet's
root public key in the multisig. This guarantees that no parties are
generating and distributing the same addresses, and also provides a
certain level of built-in book-keeping. Coins being received on chain
2*x were created by participant x (receiving), and coins received on
2*x+1 are change outputs created by participant x (outgoing). Thus,
it's easy from simply looking at the wallet structure who was
responsible for which transactions.
Alternatively, we could change it to suggest that each "device" is
assigned a pair of chains. For a 2-of-3 there may 3 participants plus a
CFO with a "watch-only" version of the multisig wallet. Then you might
use four pairs of chains. I'm just not sure how they would be assigned.
If this has been proposed before, then consider this my contribution to
documentation.
-Alan
P.S. -- "No-Collision Mode" is not a great name. Happy to take
suggestions for changing it.

2023-06-07 17:25:52

- reply

📅 Original date posted:2014-09-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/23/2014 12:37 PM, Justus Ranvier wrote:
> Would be nice if you'd at least mention our work, since we did share
> it with you back in January and have been publicly documenting it ever
> since.
>
> Or does the fact that we're implementing it in btcwallet mean what
> we're working on is unmentionable here?
>
Please don't assume poor intentions or sneaky motives. I get a lot of
emails from a lot of people about a lot of things. Nine months ago was
an eternity in this world, and it can't be ruled out that I simply forgot.
I have no problem giving credit where it is due, and I mentioned in my
first email that I wasn't sure if my stuff was original. Please
recap/link it here so that it can be part of this discussion.
- -Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X
pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z
L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU
FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK
nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc
UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9
m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M
NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM
kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd
eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY
gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF
ofeDK5BPL8H+5L3tk+1o
=tX2n
-----END PGP SIGNATURE-----

2023-06-07 17:24:37

- reply

📅 Original date posted:2014-07-30
📝 Original message:Hi Everyone,
The Armory team is pleased to announce the official release of our
decentralized multi-signature interface, called "Lockboxes". It is a
"true" multi-signature transaction interface:
* Decentralized multi-sig (no third-party servers or signers needed)
* Any multi-sig from 1-of-2 up to 7-of-7
* Any or all of the signing devices can be *offline*
* All private keys can be generated and managed independently
* Works with existing Armory wallets
* Simultaneous funding ("simulfunding") features for escrow and
contracts (basically CoinJoin)
* All wrapped up in a nice graphical user interface!
Armory 0.92 includes a GUI for creating, funding and spending from
multi-signature lockboxes, anything from 1-of-2 up to 7-of-7. All
private keys can be generated independently and never have to be
co-located. Most importantly, any number of the signing keys can be
created and managed on offline computers! Also, all transaction and
signature data is communicated directly between parties/devices using
ASCII-armored blocks of text, so no third-party servers/services are
needed (though, in the future, we hope to provide an optional service to
help synchronize the data between parties).
The release also includes the ability to do simultaneous funding
("simulfunding") which is basically CoinJoin through a GUI, but intended
to be used for contracts and escrow. Each party creates a "promissory
note" (which is basically just a list of UTXOs and a change address),
and those can be merged into a single transaction to be signed by all
funders. Either all contributions are made simutaneously, or none of
them are. There is no other outcome. This means that no trust is
required between the simulfunders. It is a basic contract enforced by
the bitcoin network itself.
Simulfunding would normally be used in conjuction with multi-signature
lockboxes -- two parties that don't trust each other together create a
lockbox, and then simultaneously fund it (and subsequently spend it)
according to some agreement. However, it can actually be used to
simulfund any address. To promote this feature, Armory Technologies Inc
is offering to match up to 20 BTC in donations to the EFF, FSF, College
Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation
(and hopefully wikipedia, as a late addition to the list). We posted
a list of ATI "promissory notes" for matching donations on our
website: https://bitcoinarmory.com/donation-match-list/
We're very excited about this release, which has been in testing for
over three months, and we've been using for management of company funds
between officers for the last two months. We have not seen anything
else that comes close to matching the flexibility and security afforded
by it (and without being exceptionally inconvenient!). See our
tutorials, and especially the FAQ at the end:
https://bitcoinarmory.com/about/using-lockboxes
https://bitcoinarmory.com/about/using-lockboxes/#faq
We hope that people will try it out and provide feedback. Maybe even
match some donations! We've already matched 3 BTC so far and it was
announced less than 24 hours ago.
Cheers,
-Alan
------
Press Release:
http://finance.yahoo.com/news/armory-releases-first-decentralized-multi-233500704.html
------
Changelog:
*VERSION 0.92**
**Released July 29, 2014**
*
- *Multi-Signature Lockboxes!*
Full-featured interface for creating multi-signature addresses,
putting money into them, and collecting signatures to spend them.
See our tutorials at:
https://bitcoinarmory.com/about/using-lockboxes/
- *Simulfunding for Addresses and Lockboxes*
Use the "Multi-Sig" menu to do prepare simulfunding to any
arbitrary address. Or click on the "Simul" checkbox in the
lockbox manager if you are simulfunding a lockbox. As a promotion
for this feature we are matching up to 20 BTC worth donations
to organizations that support Bitcoin, digital security, online
freedoms, and open-source software. See our donation list (with
instructions): https://bitcoinarmory.com/about/donation-match-list
- *Improved Mac/OSX Stability*
We merged a couple Qt4 patches that dramatically improved
compatibility on OSX 10.7 and newer. Should work with the
upcoming release of OSX 10.10.
- *Armory Daemon/API Upgrades (Beta)*
The Armory API has been upgraded substantially since version 0.91.
This version has tons of new functionality matching bitcoind,
as well as unique functionality including lockbox operations.
Plan to have complete functionality implemented and tested by
version 0.93.
- *Upgraded Transaction History Export to CSV*
Added running balance reporting for individual and all wallets.
Also fixed a bug where internal transfers within wallets were
not being reported properly.
- *Root PUBLIC Key Export*
You can now export just the root public key data that allows
you to reconstruct your watching-only wallet. It is five lines
that are easily printed or copied by hand. Could be used to
provide someone a chain of addresses for multiple payments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140730/d0ee6702/attachment.html>

2023-06-07 17:23:34

- reply

📅 Original date posted:2014-07-04
📝 Original message:On 07/04/2014 07:15 AM, Andy Parkins wrote:
> On Friday 04 July 2014 06:53:47 Alan Reiner wrote:
>
>> ROMix works by taking N sequential hashes and storing the results into a
>> single N*32 byte lookup table. So if N is 1,000,000, you are going to
>> compute 1,000,000 and store the results into 32,000,000 sequential bytes
>> of RAM. Then you are going to do 1,000,000 lookup operations on that
>> table, using the hash of the previous lookup result, to determine the
>> location of next lookup (within that 32,000,000 bytes). Assuming a
>> strong hash function, this means its impossible to know in advance what
>> needs to be available in RAM to lookup, and it's easiest if you simply
>> hold all 32,000,000 bytes in RAM.
> My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It
> wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it
> gained you a 1000x advantage over the other miners. It seems that sort of
> solution is exactly the one that Mike Hearn was warning against in his blog.
I think you misundersood.... using ROMix-like algorithm, each hash
requires a different 32 MB of the blockchain. Uniformly distributed
throughout the blockchain, and no way to predict which 32 MB until you
have actually executed it. If the difficulty is high enough, your
miner is likely to end up going through the entire X GB blockchain while
searching for a good hash, but other nodes will only need to do 32 MB
worth of disk accesses to verify your answer (and it will be unknown
which 32 MB until they do the 1,000,000 hash+lookup operations on their
X GB blockchain).
I think that strikes a good compromise of needing access to 100% of the
blockchain, without requiring reading 20 GB to verify a block.
(Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated
numbers in the future)

2023-06-07 17:23:33

- reply

📅 Original date posted:2014-07-04
📝 Original message:Just a thought on this -- I'm not saying this is a good idea or a bad
idea, because I have spent about zero time thinking about it, but
something did come to mind as I read this. Reading 20 GB of data for
every hash might be a bit excessive. And as the blockchain grows, it
will become infeasible to continue. However, what comes to mind is the
ROMix algorithm defined by Colin Percival, which was the pre-cursor to
scrypt. Which is actually what Armory uses for key stretching because
it's far simpler than scrypt itself while maintaining the memory-hard
properties (the downside is that it's much less flexible in allowing the
user to trade-off compute time vs memory usage).
ROMix works by taking N sequential hashes and storing the results into a
single N*32 byte lookup table. So if N is 1,000,000, you are going to
compute 1,000,000 and store the results into 32,000,000 sequential bytes
of RAM. Then you are going to do 1,000,000 lookup operations on that
table, using the hash of the previous lookup result, to determine the
location of next lookup (within that 32,000,000 bytes). Assuming a
strong hash function, this means its impossible to know in advance what
needs to be available in RAM to lookup, and it's easiest if you simply
hold all 32,000,000 bytes in RAM.
Something similar could be applied to your idea. We use the hash of a
prevBlockHash||nonce as the starting point for 1,000,000 lookup
operations. The output of the previous lookup is used to determine
which block and tx (perhaps which chunk of 32 bytes within that tx) is
used for the next lookup operation. This means that in order to do the
hashing, you need the entire blockchain available to you, even though
you'll only be using a small fraction of it for each "hash". This might
achieve what you're describing without actually requiring the full 20 GB
of reading on ever hash.
-Alan
On 07/04/2014 06:27 AM, Andy Parkins wrote:
> Hello,
>
> I had a thought after reading Mike Hearn's blog about it being impossible to
> have an ASIC-proof proof of work algorithm.
>
> Perhaps I'm being dim, but I thought I'd mention my thought anyway.
>
> It strikes me that he's right that it's impossible for any algorithm to exist
> that can't be implemented in an ASIC. However, that's only because it's
> trying to pick an algorithm that is CPU bound. You could protect against ASCI
> mining (or rather, make it irrelevant that it was being used) by making the
> algorithm IO-bound rather than CPU-bound.
>
> For example, what if the proof-of-work hash for a block were no longer just
> "hash of block", which contains the hash of the parent block, but instead were
> hash of
>
> [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]
>
> [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and
> suffixing the new block, you have to feed every byte of the blockchain through
> the hashing engine (the prefix prevents you caching the intermediate result).
> Whatever bus you're using to feed your high speed hashing engine, it will
> always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and
> any hashing engine will, effectively, be the same.
>
> I'm making the assumption that SHA-256 is not cacheable from the middle
> outwards, so the whole block-chain _has_ to be transferred for every hash.
>
> Apologies in advance if this is a stupid idea.
>
>
>
> Andy

2023-06-07 17:20:46

- reply

📅 Original date posted:2014-05-02
📝 Original message:I've been a strong supporter of the 1e-6 unit switch since the beginning
and ready to do whatever I can with Armory to help ease that
transition. I'm happy to prioritize a release that updates the Armory
interface to make "bits" the default unit, when the time is right. I
think it makes sense to get as many apps and services to upgrade nearly
simultaneously.
My plan is to have a popup on the first load of the new version that
briefly introduces the change, and mentions that they can go back to the
old way in the settings, but make them work to do it. For the transient
period (6 months?) all input boxes will auto-update nearby labels with
the converted-to-BTC value as they type, so that they don't have to do
any math in their head. Similarly, all displayed BTC values will show
both. But the 1e-6 unit will always be default or first unless they
explicitly change it in the interface.
On 5/2/2014 8:54 PM, Ben Davenport wrote:
> I fully support this (it's what I suggested over a year ago), but what
> it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum
> around "bits", great.
>
> My only addition is that I think we should all stop trying to attach
> SI prefixes to the currency unit. Name me another world currency that
> uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted
> standard at least in the US is <currency-symbol><amount><modifier>,
> i.e. $63k or $3M. That may not be accepted form everywhere, but in any
> case it's an informal format, not a formal one. The important point is
> there should be one base unit that is not modified with SI prefixes.
> And I think the arguments are strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> <vendor hat: on>
>
> Related:
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
> available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> 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/20140502/44cb1298/attachment.html>

2023-06-07 17:19:12

- reply

📅 Original date posted:2014-04-21
📝 Original message:On 04/21/2014 11:40 AM, Ashley Holman wrote:
> On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for the information to validate the block and
> update their UTXO sets. This results in the same problem as
> before, as the large pools who mine most blocks can validate
> either instantly - the self-mine case - or more quickly than the
> smaller miners.
>
>
> Under the headers first scenario, wouldn't the full block still reach
> everyone in the same time as it would under the current rules? So the
> small miner loses nothing in terms of updating their UTXO set, but
> gains an early "heads up" alert that a new block is coming. This
> allows them spend the propagation time working more productively on an
> empty block in the new chain rather than wasting time on an orphan.
> It's true that it doesn't solve the problem of larger pools vs
> smaller pools, but if it doesn't make it any worse then headers-first
> propagation would be a net benefit to the network since it removes the
> incentive to make small blocks.
>
I think the most important part is that nodes can reliably decide on
"first received", regardless of how they subsequently act on it. I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block, until
it has the necessary pieces to fully verify the first header received.
If that block data doesn't come, then it will be naturally ignored. But
if multiple blocks come at once, even if a competing block "verifies"
first, the node would still switch to considering the first header
received as the best block when it later receives proof it is valid
(which may only be a couple seconds).
In other words, the node will always consider the header-received time
as the primary ordering criteria, but will not mine on anything until it
has full proof of validity, even if /that/ is out of order. This means
that new blocks "effectively" propagate at the speed of 80 bytes, which
limits certain kinds of block-injection/racing attacks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/b0ca4320/attachment.html>

2023-06-07 17:18:59

- reply

📅 Original date posted:2014-04-20
📝 Original message:Btw, I should clarify my email: I'm a staunch supporter of moving to
1e-6 BTC as the default unit for wallet applications, not necessarily
any particular name. I would be fine with "bits" as I think this
context is sufficiently different that it won't be confused by regular
consumers. But it wouldn't be my first choice. I don't know what my
first choice would be.
While writing this email, I asked my wife (who's been tired of hearing
about Bitcoin for two years), what she thinks of "bits", "microbes",
"micros". She said she is fine with any of them. Apparently microbes
reminders her of biology, not "germs". But she's also well-educated, so
she fine with milli, micro, kilo, etc... and apparently biology...
Whatever we call it. I'm happy to support it as long as it's 1e-6.
On 04/20/2014 12:23 PM, Erik Garrison wrote:
>
> The world is rapidly becoming a place in which a solid grasp of orders
> of magnitude could be considered a basic mathematical skill. People
> are very likely to learn what mBTC and µBTC are simply because they
> risk their money if they do not. This is not a bad thing and I think
> stands only to help people who learn about these monikers for orders
> of magnitude this way.
>
> Any appropriate nicknames for these denominations is sure to develop
> in due course. Promoting an already-overloaded term that could just
> as easily be applied colloquially to refer to a small amount of value
> in any currency seems problematic.
>
> I've been a staunch supporter of "microbitcoin" and would like to do
> anything I can to make sure that we jump directly to it if we're going
> to promote changing the default units. And I'm happy to integrate it
> into Armory as a default (with appropriate explanations and
> settings/options). I'm not so convinced about the "bits" name though
> -- I do like it, but I do also think that word is too overloaded.
> Though, I think we could get away with it.
>
> (Sadly, I still use "microbes" occasionally (as in *microb*itcoin)
> when I'm talking to coworkers, because it slips off the tongue and is
> actually a good combination of brevity and self-explanatory -- it just
> doesn't instill the right visuals...)
>
> We started integrating alternative units into Armory. But, of course,
> there were a few more loose ends than I expected, which will require
> some work. We want to put it in but not necessarily change the
> default right away. I'd /prefer/ we get some commitments from some
> other wallet developers, so we can make a unified push for it. I'm
> happy to lead that and make it default as long as I'm not the only one
> in the world doing it.
>
> -Alan
>
>
>
> On 04/20/2014 11:05 AM, Tamas Blummer wrote:
>> Here is an earlier reference to bits:
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
>> <https://www.mail-archive.com/[email protected]/msg04248.html>
>>
>> I forgot that Alan Reiner was also supporting a unit equals to bits :
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
>> <https://www.mail-archive.com/[email protected]/msg04264.html>
>>
>> and here the earlier going back to March 2013 and a poll at that time
>> pushing for XBT being 1 bit
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
>> <https://www.mail-archive.com/[email protected]/msg04256.html>
>>
>> Regards,
>>
>> Tamas Blummer
>> http://bitsofproof.com
>>
>> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com
>> <mailto:pieter.wuille at gmail.com>> wrote:
>>
>>> I told him specifically to bring it here (on a pull request for
>>> Bitcoin Core), as there is no point in making such convention changes
>>> to just one client.
>>>
>>> I wasn't aware of any discussion about the "bits" proposal here before.
>>>
>>> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer
>>> <tamas at bitsofproof.com <mailto:tamas at bitsofproof.com>> wrote:
>>>> People on this list are mostly engineers who have no problem
>>>> dealing with
>>>> magnitudes and have rather limited empathy for people who have a
>>>> problem
>>>> with them.
>>>> They also tend to think, that because they invented money 2.0 they
>>>> would not
>>>> need to care of finance's or people's current customs.
>>>>
>>>> The importance of their decisions in these questions will fade as
>>>> people
>>>> already use wallets other than the core.
>>>>
>>>> Bring this particular discussion elsewhere, to the wallet developer.
>>>>
>>>> BTW the topic was discussed here several times, you have my support
>>>> and Jeff
>>>> Garzik's.
>>>>
>>>> Regards,
>>>>
>>>> Tamas Blummer
>>>> http://bitsofproof.com
>>>>
>>>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com>
>>>> <mailto:rob.golding at astutium.com> wrote:
>>>>
>>>> The average person is not going to be confident that the prefix they
>>>> are using is the correct one,
>>>>
>>>>
>>>> The use of any 'prefix' is one of choice and entirely unnecessary,
>>>> and there
>>>> are already established 'divisions' in u/mBTC for those that feel
>>>> they need
>>>> to use such things.
>>>>
>>>> people WILL send 1000x more or less than
>>>> intended if we go down this road,
>>>>
>>>>
>>>> Exceptionally unlikely - I deal every day with currencies with 0, 2
>>>> and 3
>>>> dp's in amount ranging from 'under 1 whole unit' to tens of
>>>> thousands - Not
>>>> once in 20 years has anyone ever 'sent' more or less than intended
>>>> - oh,
>>>> they've 'intended' to underpay just fine, but never *unintended*.
>>>>
>>>> I propose that users are offered a preference to denominate the
>>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>>>
>>>>
>>>> I propose that for people unable to understand what a bitcoin is,
>>>> they can
>>>> just use satoshi's and drop this entire proposal.
>>>>
>>>> Rob
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases
>>>> and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases
>>>> and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>>
>>
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/f67ef7e9/attachment.html>

2023-06-07 17:18:55

- reply

📅 Original date posted:2014-04-20
📝 Original message:I've been a staunch supporter of "microbitcoin" and would like to do
anything I can to make sure that we jump directly to it if we're going
to promote changing the default units. And I'm happy to integrate it
into Armory as a default (with appropriate explanations and
settings/options). I'm not so convinced about the "bits" name though --
I do like it, but I do also think that word is too overloaded. Though,
I think we could get away with it.
(Sadly, I still use "microbes" occasionally (as in *microb*itcoin) when
I'm talking to coworkers, because it slips off the tongue and is
actually a good combination of brevity and self-explanatory -- it just
doesn't instill the right visuals...)
We started integrating alternative units into Armory. But, of course,
there were a few more loose ends than I expected, which will require
some work. We want to put it in but not necessarily change the default
right away. I'd /prefer/ we get some commitments from some other wallet
developers, so we can make a unified push for it. I'm happy to lead
that and make it default as long as I'm not the only one in the world
doing it.
-Alan
On 04/20/2014 11:05 AM, Tamas Blummer wrote:
> Here is an earlier reference to bits:
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
> <https://www.mail-archive.com/[email protected]/msg04248.html>
>
> I forgot that Alan Reiner was also supporting a unit equals to bits :
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
> <https://www.mail-archive.com/[email protected]/msg04264.html>
>
> and here the earlier going back to March 2013 and a poll at that time
> pushing for XBT being 1 bit
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
> <https://www.mail-archive.com/[email protected]/msg04256.html>
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
>> I told him specifically to bring it here (on a pull request for
>> Bitcoin Core), as there is no point in making such convention changes
>> to just one client.
>>
>> I wasn't aware of any discussion about the "bits" proposal here before.
>>
>> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com
>> <mailto:tamas at bitsofproof.com>> wrote:
>>> People on this list are mostly engineers who have no problem dealing
>>> with
>>> magnitudes and have rather limited empathy for people who have a problem
>>> with them.
>>> They also tend to think, that because they invented money 2.0 they
>>> would not
>>> need to care of finance's or people's current customs.
>>>
>>> The importance of their decisions in these questions will fade as people
>>> already use wallets other than the core.
>>>
>>> Bring this particular discussion elsewhere, to the wallet developer.
>>>
>>> BTW the topic was discussed here several times, you have my support
>>> and Jeff
>>> Garzik's.
>>>
>>> Regards,
>>>
>>> Tamas Blummer
>>> http://bitsofproof.com
>>>
>>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>>>
>>> The average person is not going to be confident that the prefix they
>>> are using is the correct one,
>>>
>>>
>>> The use of any 'prefix' is one of choice and entirely unnecessary,
>>> and there
>>> are already established 'divisions' in u/mBTC for those that feel
>>> they need
>>> to use such things.
>>>
>>> people WILL send 1000x more or less than
>>> intended if we go down this road,
>>>
>>>
>>> Exceptionally unlikely - I deal every day with currencies with 0, 2
>>> and 3
>>> dp's in amount ranging from 'under 1 whole unit' to tens of
>>> thousands - Not
>>> once in 20 years has anyone ever 'sent' more or less than intended - oh,
>>> they've 'intended' to underpay just fine, but never *unintended*.
>>>
>>> I propose that users are offered a preference to denominate the
>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>>
>>>
>>> I propose that for people unable to understand what a bitcoin is,
>>> they can
>>> just use satoshi's and drop this entire proposal.
>>>
>>> Rob
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> 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/20140420/542338d8/attachment.html>

2023-06-07 17:16:42

- reply

📅 Original date posted:2014-03-29
📝 Original message:Armory does exactly this: it defines the "Fragment ID" as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58. Then it explains to the user "All fragments with the same
fragment ID are compatible" (which only works if you use deterministic
coefficients). Each fragment is then labeled with "[FragID]-#1",
"[FragID]-#2", etc. It became quite useful for organizing the fragments
and documenting how I was distributing them, especially if I had printed
or saved the same fragment twice by accident.
On 03/29/2014 02:16 PM, Tamas Blummer wrote:
> I also think that we can add usability features if the underlying
> secret remains well protected.
> I do not think there is any reason to assume that the knowledge of the
> degree of the polynomial, would aid an attacker.
>
> Similarly a fingerprint of the secret if it is unrelated to the hash
> used in the polinomyal should leak no useful information,
>
> The length of such fingerpring (say 4 bytes) and the degree (1 byte)
> does not seem a big overhead for me.
>
> Remember that the biggest obstacle of Bitcoin is usability not security.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 29.03.2014, at 18:52, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from
>>> the shares because including it would give an adversary a vital
>>> piece of information. Likewise, including any kind of information
>>> that would allow a determination of whether the secret has been
>>> correctly reconstituted would give an adversary too much
>>> information. Failing silently when given incorrect shares or an
>>> insufficient number of shares is intentional.
>>
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/8e874f60/attachment.html>

2023-06-07 17:16:41

- reply

📅 Original date posted:2014-03-29
📝 Original message:On 03/29/2014 02:00 PM, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
> For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)
Regardless of how SSSS does it, I believe that obfuscating that
information is bad news from a usability perspective. Undoubtedly,
users will make lots of backups of lots of wallets and think they
remember the M-parameter but don't. They will accidentally mix in some
3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
or not able to distinguish them. Or they'll distribute too many
thinking the threshold is higher and end up insecure, or possibly not
have enough fragments to restore their wallet thinking the M-value was
lower than it actually was.
I just don't see the value in adding such complexity for the benefit of
obfuscating information an attacker might be able to figure out anyway
(most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
he doesn't know where the other frags are and they are actually in
safe-deposit boxes)

2023-06-07 17:16:13

- reply

📅 Original date posted:2014-03-26
📝 Original message:This might be tangential, but the comment about "refund" chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1. Your spouse's
phone would use chains 2 and 3.
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan
On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20140326/35055a7c/attachment.html>

2023-06-07 17:16:05

- reply

📅 Original date posted:2014-03-25
📝 Original message:I would echo the need for some kind of moderation.
I believe Peter Todd is an extremely intelligent individual, who has a
lot to offer the Bitcoin community. He has a firm grasp of a lot of
really deep Bitcoin concepts and his *technical* insight is generally
positive. Technically. But the way he communicates on this list is
*extremely* corrosive and breeds hostility. It makes it a scary place
to discuss things, with frequent, public ridicule of everything posted.
I agree that I would rather have a friendly environment to discuss
technicals, even if it means losing additional technical insight.
People who would explicitly insult other contributors intelligence and
character on a public list should be subject to some kind of negative
reinforcement. Maybe there's solutions other than outright banning.
-Alan
On 03/25/2014 01:37 PM, Jeff Garzik wrote:
> On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
>> For someone with 'Chief Scientist' as their job title, I'm surprised you
>> think so little of hard evidence and so much of idol worshipping.
> Peter, take this unprofessional, personal crap off-list.
>
> Mike's anecdote of hostility is not an isolated one. Just today, a
> bitcore developer commented on "Peter Todd's ..apocalyptic vision
> and... negative view on bitcoin" which turned off some other
> developers from participating more interactively.
>
> As I commented on IRC, open source projects are no strangers to people
> who simultaneously (a) make useful contributions and (b) turn
> potential contributors away with an abrasive or hostile attitude
> toward others. It's an unsolved problem in OSS, that I saw for 15+
> years in the Linux kernel community.
>
> For this list, as Mike suggested on IRC, introducing an openly stated
> moderation policy may be the one route.
>

2023-06-07 17:15:37

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 01:24 PM, Mike Hearn wrote:
>
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there
> was a
> suggestion to use 1 XBT == 1 uBTC.
>
>
> Unfortunately I think some people already started using XBT to mean
> the same as BTC (another ship that sailed: somehow Bhutan will have to
> live with it). So if some software started to redefine it to mean
> something else, that seems like a recipe for accidentally sending far
> too much or too little money by mistake.
>
There is also the benefit that if someone screws up BTC and uBTC, it's
likely to fail. Most people don't have 1e6 times as much money in their
wallet as they attempted to send in a single transaction. Similarly,
sending one-millionth of what you meant to is likely invalid or below
the dust limit.
Well it looks like the consensus is to do it, instead of talking about
it. I'm going to make sure we get uBTC into the next Armory release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/be24b2d1/attachment.html>

2023-06-07 17:15:37

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 01:51 PM, Mike Hearn wrote:
>
> Well it looks like the consensus is to do it, instead of talking
> about it. I'm going to make sure we get uBTC into the next Armory
> release.
>
>
> Hmm - be careful with the word "consensus" here. A bunch of people on
> a mailing list does not make consensus ;)
>
> If you survey other wallets, you'll find most already switched to
> mBTC, that it took some effort to do so (look at the size of the
> patches for instance) and that probably, nobody is super-keen to
> change again so soon. So uBTC would make you different to most of the
> other wallets and services in wide usage.
>
> If Armory wants to do that, that's no problem, maybe it will be a
> competitive advantage - just saying, don't quote this thread as
> indicating some kind of community consensus.
>
> Wallets and services that are using mBTC (that I know of)
>
> blockchain.info <http://blockchain.info>
> MultiBit
> Bitcoin Wallet (Android)
> Hive
> Bitcoinity
> KnC Wallet (defaults to BTC but can be switched to mBTC in settings,
> uBTC not an option)
> Mullvad
> btcstore.eu <http://btcstore.eu>
>
> Doing a google search for [bitcoin "mBTC"] and [bitcoin "uBTC"], the
> former has a bunch of sites and services with prices in mBTC. The
> latter only has faucets, as far as I can tell, which sort of makes sense.
I actually was not aware that so many had already switched to mBTC. I
guess it shows how much I use other wallets.
You misunderstood my "consensus" comment. I was simply stating the
"consensus" of debating on the mailing list endlessly is not as
effective as doing it. Thus I was just going to do it and see who
follows. But that also assumed there was not a critical mass who'd
already switched -- I must admit I'm not so confident anymore...
I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to
take a small leap of faith (with associated risks), to help push the
"consensus". Of course it would still remain configurable, but the
default will make a big difference.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/d0586965/attachment.html>

2023-06-07 17:15:35

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 10:32 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike at plan99.net> wrote:
>> BitPay should use mBTC as well. Unless you can point to any major wallets,
>> exchanges or price watching sites that use uBTC by default?
>>
>> I think it is highly optimistic to assume we'll need another 1000x shift any
>> time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard
> Such hand-wavy, data-free logic is precisely why community
> coordination is preferred to random apps making random decisions in
> this manner.
>
> mBTC is problematic because you do not need 1000x shift in value to
> produce annoyances for major accounting packages that are hard-limited
> to two decimal places. Further, spreadsheets hide information if
> formatting is configured naively -- that is, if formatting is
> configured for bitcoin the way it is configured for other currencies.
>
> Fundamentally, more than two decimal places tends to violate the
> Principle Of Least Astonishment with many humans, and as a result,
> popular software systems have been written with that assumption.
>
I whole-heartedly agree with Jeff. micro-BTC was the way to go to end
user confusion and make things easier for software systems which are
designed to handle money (i.e. two decimal places). I also echo the
sentiment about people being able to handle large numbers well.
We've been working with Marty Zigman who's creating a Bitcoin plugin for
NetSuite accounting platform, and he was already forced to switch
micro-BTC long ago for exactly the reasons described above. I think the
system will track up to 3 decimal places without causing all sorts of
heartache and automatic rounding.
Of course, as Mike said, this ship may have already sailed, but if
there's any way to revisit this, I'm there. We're just about to do
another Armory release and could support this very easily.

2023-06-07 17:15:02

- reply

📅 Original date posted:2014-03-10
📝 Original message:Then of course I tried to do this with BIP 10
<https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
Armory implemented offline-transactions two years ago. I got some
positive feedback, but no one wanted to help improve it, etc. I guess
nobody else was doing it and/or cared at the time. So I continue to use
BIP 10 even though it's pretty crappy. I wanted it to be useful for
multisig, too, but it has some deficiencies there (it was done when
Armory was extremely young and OP_EVAL was still on the table).
However, with all this activity, we should start thinking about that and
discussing it. Otherwise, I'll just do my own thing again and probably
end up with something that fits my own needs, but not anyone else's.
Really though, multisig shouldn't require all the same app to work.
-Alan
On 03/10/2014 01:49 PM, Gavin Andresen wrote:
> In my experience, best process for standardizing something is:
>
> 1) Somebody has a great idea
> 2) They implement it
> 3) Everybody agrees, "Great idea!" and they copy it.
> 4) Idea gets refined by the people copying it.
> 5) It gets standardized.
>
> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
> opinion...
>
>
>
>
> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
> <mailto:drak at zikula.org>> wrote:
>
> I was wondering if there would be merit in a kind of BIP for a
> payment protocol using multisig?
>
> Currently, setting up a multisig is quite a feat. Users have to
> exchange public keys, work out how to get the public keys from
> their addresses. If one of the parties are not savvy enough, an
> malicious party could easily be setup that was 2 of 3 instead of 2
> of 2 where the malicious party generates the multisig
> address+script and thus be able to run off with funds anyway.
>
> It's also terribly complex to generate and keep track of. There's
> been a nice attempt at creating an browser interface at
> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
> the kind of ease with created by the payment protocol. If there
> was a BIP then it would go a long way to aiding future usability
> of multisig wallet implementations.
>
> What are your thoughts?
>
> Drak
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
> and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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
>
>
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> 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/20140310/2e157654/attachment.html>

2023-06-07 17:13:22

- reply

📅 Original date posted:2014-02-12
📝 Original message:Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a
problem. I would love to be able to leverage chained TX for Bitcoin
contracts. But that in its current state it doesn't have to be complicated
to deal with it.
Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin. But they can still be useful
at the application level to mitigate these issues.
Sent from my overpriced smartphone
On Feb 12, 2014 11:38 AM, "Allen Piscitello" <allen.piscitello at gmail.com>
wrote:
> While that solution does work for many use cases, it does make it much
> harder to do anything needing chained transactions. Granted, this is the
> short term solution for current implementations, but having a transaction
> identifier that does not change does open up other use cases.
>
> For example, Alice wants to send coins to a multisignature address with
> Bob, such that both parties are required to spend the coins. Alice also
> requires for Bob to send coins to this address as well before they will
> proceed. Alice cannot guarantee that Bob will cooperate (and vice versa),
> so before she broadcasts the transaction to send to A+B, she sends Bob a
> transaction that spends her incoming transaction back to herself, but has a
> time lock of far into the future. Bob signs this, returns it to Alice, and
> she broadcasts her funding transaction. At this point, Bob disappears,
> loses his key, or just decides to spite Alice and her coins are locked.
> Since she has a refund transaction, she can broadcast it in a month and
> get her coins back. Except her funding transaction has been modified such
> that the txhash is different, so her refund is now invalid. She would need
> Bob to issue a new refund as soon as her funding transaction hits the
> blockchain if it is modified, which defeats the point of the trustless
> refund transaction.
>
> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if wallets are able to properly identify the status of it's
> transactions. Obviously this is a difficult problem to solve and cannot be
> implemented without breaking changes, but it would be a nice goal to be
> able to completely remove malleability. There are other important use
> cases where having a unique identifier just for internal accounting is
> insufficient.
>
> -Allen
>
>
> On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
>> I think the solution is simply to encourage Bitcoin software developers
>> to design their software to use this static ID, instead of the full
>> transaction hash. If MtGox had talked those IDs instead of the TX ID,
>> their software would've correctly identified the mutated transactions and
>> there would be no problem.
>>
>> Armory is slightly different, since it doesn't deal with the same stuff
>> as exchanges do. But it didn't have any problems with malleability because
>> it doesn't track anything by ID, it only pays attention to whether inputs
>> and outputs are related to your wallets. It's not necessarily hard to do
>> it this way, people just have to be aware of it.
>>
>> -Alan
>>
>> Sent from my overpriced smartphone
>> On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com>
>> wrote:
>>
>>> Instead of trying to remove the possibility of transaction
>>> malleability, would it make sense to define a new, "canonical
>>> transaction hash/ID" (cTxID), which would be a hash of the part of the
>>> transaction data which we know is not malleable, and have clients use
>>> this cTxID internally, thus making the traditional transaction hash
>>> irrelevant for a client to function correctly?
>>>
>>> We already have a non-malleable transaction hash: the hash that is
>>> signed, ie. the transaction with each scriptSig replaced by the
>>> scriptPubKey it redeems. This could be the cTxID.
>>>
>>> Or is this simply a too fundamental change to the way bitcoin-qt (and
>>> all other clients) work in order to be feasible?
>>>
>>> As far as I can see, it completely solves the issue of not having a
>>> canonical ID for a transaction, but it also increases the
>>> computational requirements for a node. For one, as far as I can see,
>>> it requires the node to index all transactions, because in order to
>>> calculate a cTxID, it would be necessary to fetch all transactions
>>> referred to by the transaction in question, in order to pull in the
>>> scriptPubKeys that are redeemed.
>>>
>>>
>>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
>>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>>> >> Hello all,
>>> >>
>>> >> it was something I planned to do since a long time, but with the
>>> >> recent related issues popping up, I finally got around to writing a
>>> >> BIP about how we can get rid of transaction malleability over time.
>>> >>
>>> >> The proposed document is here: https://gist.github.com/sipa/8907691
>>> >>
>>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>>> >> they require modifications to wallet software (Bitcoin Core 0.9 and
>>> >> BitcoinJ already implement it, though) and potentially invalidate some
>>> >> script functionality. However, these new rules remain optional and
>>> >> controlled by an nVersion increase.
>>> >>
>>> >> Comments please!
>>> >
>>> > You should probably add making CHECKMULTISIG require the dummy value to
>>> > be exactly equal to OP_FALSE; verifying that in the transaction itself
>>> is
>>> > laborious. A more subtle example is we may want both CHECKSIG and
>>> > CHECKMULTISIG to fail the transaction if the signature is invalid but
>>> > not exactly equal to OP_FALSE; some transaction forms are significantly
>>> > more compact if you can have failed signatures, but that's a source of
>>> > malleability. (are there counter examples people can think of?)
>>> >
>>> >
>>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
>>> > malleability when we have no solid idea if ECC signatures are or are
>>> not
>>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability
>>> is
>>> > all we've got it could be ugly if a break is found. Similarly, we may
>>> > find we missed something, or some needed change makes the malleability
>>> > rules difficult to work with for some new script type that is required.
>>> >
>>> > I'd rather see a new CHECKSIG mode for the case where malleability
>>> > absolutely must be eliminated - certain multi-party protocols - and fix
>>> > wallet software instead. (the malleability problems people see are
>>> > closely related to inability to handle double-spends and reorgs) But I
>>> > can easily see that being an impossible goal engineering wise...
>>> >
>>> > --
>>> > 'peter'[:-1]@petertodd.org
>>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/aab9621c/attachment.html>

2023-06-07 17:09:39

- reply

📅 Original date posted:2013-11-14
📝 Original message:I really like the XBT idea. It makes a lot of sense to match the ISO
currency symbol (though the ISO guys will have to adjust the way they've
defined the "XBT"). And I do agree that going right to uBTC and
skipping mBTC makes sense, too.
I'd prefer them not be called "micro bitcoins." I really want to call
them "microbes" ... but I'm not sure that has the right flavor for money
transfer :) "Please give me 872 microbes". Perhaps we just call them
"bits." Or even "micros" or "microbits". As I write this, I realize
there's probably 872 threads on the forums about this already...
But we would want to promote a consistent term, to avoid further
confusion when people use different names for the new unit. It's not
guaranteed to be successful, but if we pick a good name, and build it
into the interface on the first release pushing the new unit, we have a
chance to make the transition even easier.
On 11/14/2013 05:31 PM, Mark Friedenbach wrote:
> Whoops, this was meant for the list:
>
> Drawing on analogues from national currencies, it's also possible to
> alleviate the confusion by switching currency symbols, e.g. to XBT or
> NBC (New Bitcoin).
>
> 1 XBC == 1 uBTC
>
> On 11/14/13 2:03 PM, Jeff Garzik wrote:
> > Go straight to uBTC. Humans and existing computer systems handle
> > numbers to the left of the decimals just fine (HK Dollars, Yen).
> > The opposite is untrue (QuickBooks really does not like 3+ decimal
> > places).
>
> > - Jeff
>
> > On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark at monetize.io
> > <mailto:mark at monetize.io>> wrote:
>
> > For this reason I'm in favor of skipping mBTC and moving straight
> > to uBTC. Having eight, or even five decimal places is not intuitive
> > to the average user. Two decimal places is becoming standard for
> > new national currencies, and we wouldn't be too far from human
> > scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't
> > think very many people on this list would consider bitcoin
> > overvalued in the long term perspective.
>
> > Better to go through a confusing renumbering only once.
>
> > Mark
>
>
------------------------------------------------------------------------------
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/c8bca901/attachment.html>

2023-06-07 17:05:38

- reply

📅 Original date posted:2013-08-07
📝 Original message:On 08/07/2013 05:10 PM, Gavin Andresen wrote:
> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ? The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>
I have avoided any notion of locking inputs in Armory for offline
wallets. The underlying concept of why a seemingly-random amount of
funds are inaccessible at a given time is so non-intuitive and difficult
to explain to a non-expert, that I haven't even tried to deal with it.
Luckily, most users do one operation at a time, so it's not a real a
problem. But as more businesses have started to use Armory, it /will/
become a problem that will need to be addressed /somehow/.
I have considered at least "marking" inputs to indicate to the user that
the transaction they are creating may not be valid unless all previous
transactions have been broadcast. The user will not necessarily
understand why, but they might easily comprehend the solution (and
perhaps a button that says "Forget all previously created transactions
that haven't been broadcast. Press this button if there are no
transactions waiting to be broadcast").
Even if the user somewhat understands the concepts behind locking, you
easily end up with a mess of some coins being locked and rejecting
transaction creation somewhat randomly, especially when they create
transactions that they later decide not to execute. And you have to
give the user a way to manually unlock the outputs which they wouldn't
know to use because it's so non-intuitive. I'd much rather say "either
do one transaction at a time, or bundle payments into a single
multi-output transaction. Or risk invalid transactions that have to be
re-created and signed."
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130807/56158e53/attachment.html>

2023-06-07 17:05:33

- reply

📅 Original date posted:2013-08-05
📝 Original message:Indeed. You can hardcode a "distributor" public key in the software,
and client software will only trust signed data from that key. Of
course, the private key for that data is not kept on the server
distributing the signed checksums. Ideally it would be kept offline,
and the couple-times-per-year that you actually execute an upgrade, you
sign the new checksums offline and upload the signed checksum to the
distribution server. Then even if the server is compromised, the
client-side software will not accept a bogus checksum because it won't
bear the right signature.
If you do this, it would be good to also have some kind of revocation
process that can be used in the event of the offline key being
compromised. You won't be able to "switch" keys, as that would defeat
the purpose (the attacker who compromises the offline key could just
issue a replacement with his own). Instead, it would be an irreversible
broadcast that would force clients to start rejecting updates from that
key. If the key is compromised (and find out), you broadcast the
revocation and the users will stop auto-updating, and be given a warning
that they should manually upgrade the software through trusted
channels. It's not failproof, but it's a decent way to minimize damage
if you discover compromise early enough.
-Alan
On 08/05/2013 11:54 AM, Daniel F wrote:
> If you want package authentication, you should at least throw in some
> digital signing, not just a checksum. With a compromised host, both the
> checksum and binaries can be changed undetectably, but if there's a
> signature made by a key that is not kept on the host, there's no way to
> fake a valid binary.
>
> There may be other issues people would want to bring up, but surely just
> a checksum is not sufficient.
>
> on 08/05/2013 10:39 AM Wendell said the following:
>> For usability purposes, we at Hive would like to have an
>> auto-updater
> in our wallet app.
>> What is a safe way to do this? I understand that Bitcoin-QT lacks
>> such
> an updater for security reasons... Has been thought out in more detail
> since that decision was made?
>> We have been toying around with the idea of placing one server
>> behind
> a Tor hidden service, whose only function is to output a checksum of the
> update package. The theory is that if it is well-secured, it will at
> least be immune to tampering at the physical hosting level.
>> Any thoughts or advice about any of this?
>> -wendell
>>
>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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 17:03:27

- reply

📅 Original date posted:2013-06-18
📝 Original message:_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a "Wallet ID" and "One-time payment" code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party. For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.
_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling
it "wallet-linkable" addresses, which would be an optional second form
for sending someone your address. With BIP 32, the address is computed
by the payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)
What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own. This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same. Remember, this is _optional_ for the
person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the "chaincode" (I think Pieter started
calling it the "tweak"). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode. But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet. It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.
*_Use Cases:_*
(1) So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner. After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it. If the payee's system is compromised and address
is replaced, the address received by the payer won't validate. This
doesn't help if the side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}. When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match. If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so.
_*Downsides:*_
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software. Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses. The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script). The blockchain still benefits from the "compression" of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee. But it
may not /really/ be a problem, given the benefits. It might just be
slightly longer strings to exchange during initialization and for each
transaction.
I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130617/d52177a4/attachment.html>

2023-06-07 17:02:48

- reply

📅 Original date posted:2013-06-05
📝 Original message:The two most basic ways would be simply:
(1) You create your transactions having a locktime of X days and has
sequence numbers such that it can be replaced exactly once. The
replacement, can be executed within 30 days.
(2) You simply send money to 1-of-2 transactions: me-or-you. If the
person who is receiving it wants it, they have to sign for it by sending
it to one of their own single-sig addresses. Otherwise, you can return
it to yourself at some point in the future.
I don't totally understand the goal, and how/if these solutions actually
achieve such goal. But it does add a way for transactions to exist a
non-final state for some amount of time. But in both cases,
accessibility is still binary: you have complete access to it, until
you don't. Which might be seen as the point of irrevocable transfer.
-Alan
On 06/05/2013 08:19 PM, Peter Vessenes wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable
> payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking
> large corporations taking money from consumers over fraudulent
> reversals. Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will
> sign at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period
> when you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a
> trusted escrow service, and is vulnerable to griefing, but I thought
> I'd see if some of the brighter minds than me can come up with a
> layer-on approach here.
>
> When I think about it, I can imagine that I would put a good number of
> my coins in a one day reversible system, because I would have warning
> if someone wanted to try and spend them, and could do something about
> it. I'm not sure if it gets me anything over a standard escrow
> arrangement, though.
>
> Peter
>
> --
>
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter at coinlab.com <mailto:peter at coinlab.com> * / 206.486.6856
> / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> 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/20130605/a7e538e5/attachment.html>

2023-06-07 17:02:00

- reply

📅 Original date posted:2013-05-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You can do this right now, with Armory. If you switch Armory to Expert
usermode, you can combine coin-control with unsigned transactions to do
exactly this. It's because Armory doesn't "lock" coins used in previous
unsigned transactions, until they're actually broadcast and confirmed to
be "out in the wild". This was done for simplicity to avoid people
getting arbitrarily-locked coins, even though it means you end up
accidentally double-spending if you try to create two different unsigned
transactions from the same wallet without sign&broadcasting the first one.
So here's what you do:
(1) Switch to "Expert" usermode in Armory
(2) Open any wallet (you don't need a watch-only wallet, full wallet is
fine)
(3) In the "Send Bitcoins" window, click coin-control
(4) Create a transaction using one sufficiently large input
(5) Click "Create Unsigned Transaction" and save it
(6) Repeat 3-5 with the same coin, but sending to yourself, specify a
larger fee
(7) Go into "Offline Transactions" and "Sign and Broadcast Transactions"
(8) Load tx1, sign & broadcast
(9) Load tx2, sign & broadcast
This only works if your Bitcoin-Qt/bitcoind client has the
replace-by-fee patch, since Armory uses Bitcoin-Qt/bitcoind as a gateway
to the network. Otherwise, the second tx will be DOA. But you don't
have to mess with Armory other than switching it to Expert mode to get
to the coin-control feature.
- -Alan
P.S. -- If you try this, Armory is likely to not show the second tx as
having ever happened (Bitcoin-Qt will send it back to us and we ignore
it because we already have a tx). But if your Bitcoin node has the
modification, it /will/ reach the network
On 05/15/2013 08:19 AM, Peter Todd wrote:
> On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote:
>> So I'm offering 2BTC for anyone who comes up with a nice and easy to use
>> command line tool that lets you automagically create one version of the
>> transaction sending the coins to the desired recipient, and another
>> version sending all the coins back to you, both with the same
>> transaction inputs. In addition to creating the two versions, you need
>> to find a way to broadcast them both simultaneously to different nodes
>> on the network. One clever approach might be to use blockchain.info's
>> raw transaction POST API, and your local Bitcoin node.
>
> Oh, and while we're at it, a good starting point for your work would be
> Gavin's spendfrom utility in the contrib/spendfrom directory in the
> Bitcoin-QT respository.
>
> Also please do keep in mind that it's much better for the community if
> an attack is demonstrated first, followed by releasing the code some
> time later.
>
>
>
>
------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRk441AAoJEBHe6b77WWmFZNQP/02t6cQkhih/CcA1oSCM72np
KMRW0Z+piHShORxLyhMX3cIpi3ICJ2lJ/Pm6GfDn74oSHq8wipIFoV88xhy810bL
MnJtbPH900v8PHh/ji2nWMig9NibeUa1zV9/tp31rYjUT3mmMoC4yQlyxKII8GWK
iignkAHV/UL5kQGmhmr1RKN127cthSMeIzAYWXfIWVObPNm85pvizVZdgqzSK73h
vwdfeFOelNbVn8ZCNT19OsxWfAKZSaBMywAX95wQBs0BtY2ZgDRmeXa6MdQKpXGW
KP3O2zjjJC2CKc4+L6elMfsoL1doEsk35w/GuI4HZK4MLAI8BChi6ZPnAYjdRvir
eHeszyxkKDCEaJ9JPLA/AszqkYHIB+56wTtrpVb1duyTwuqgVT5dcpMPIH8bDqjq
k3I8C9zCSeQ6JgyvOd8grKJchRtq0SOWYt2bB3ytePzwOs+W+6mRenb/WtMt2dQg
ntDTEIG7pCsWHenipeTBzvJNqeSsAAoIXnkGY20iDxCB+uFkTzisoCQqpOIglArm
vD+Cl2nv3OKU3NTVTUt2VinoFskezI7xvsxHD8xs2V/hrlpPbPRAo+l7ER6aTazj
wrONfmllHSE2XCM7wb/bX3gBNmsM3zUIgSBmNSH/SQeTy8PvwvlkZ/RRYmtVSmHL
rUTp7x4U63JiIDO1jj+T
=JiPo
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130515/9f78f5e6/attachment.html>

2023-06-07 13:46:33

- reply

📅 Original date posted:2013-04-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/14/2013 02:25 AM, Peter Todd wrote:
> On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
>> If we're going to extend/expand message signing, can we please add a
>> proper ASCII-armored format for it? Really, anything that encodes the
>> signed message next to the signature, so that there's no ambiguities
>> about what was signed. You can keep the "bare signatures" as an option
>> for backwards compatiblity, but offer this as the primary one.
>>
>> What we really want is to have the user copy an ASCII-armored block of
>> text into the client (or we could have a URI-extension for this), and
>> the app pops up with a window that says "The following message has a
>> valid signature from address 1XKjf32kJbf...: <message>".
>
> I already looked into ASCII-armoring PGP style for a different project.
> (timestamping) Basically you'd want to follow RFC2440, section 7
> "Cleartext signature framework":
>
> -----BEGIN BTC SIGNED MESSAGE-----
>
> Hello world!
> -----BEGIN BTC SIGNATURE-----
> IKBeCbxXHvD1TJh8ZlMySo26w5z6YZQD1xqKgbhsvlhEgcFD+kvKx4LzUz1yxg/8
> IdYdBnzez77VDq3odHrVftg=
> -----END BTC SIGNATURE-----
>
> Pretty simple really and doesn't need to be done prior to other
> signmessage changes. There may be an issue passing \r's through the RPC
> interface; the RFC specifies CRLF line endings.
>
Perfect. That was the spec I was looking for but too lazy to find it.
I guess I'll lead by example and just do it in Armory. I'll let users
pressure the other devs to follow :)
- -Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFq9GIACgkQYdHIW5RKKv1A2gCeMfdttPylmPqPqemo0Q2uACEt
eAcAn21a7sYy+TNIinRR3SlVgm4VbJPh
=qGlo
-----END PGP SIGNATURE-----

2023-06-07 12:45:47

- reply

📅 Original date posted:2012-12-04
📝 Original message:My personal opinion is that the ideal first client has three features:
(1) Starts up and is usable within a couple minutes (even 10 min the first
time would be okay, to sync block headers)
(2) Supports Windows, Linux and OSX
(3) Uses deterministic wallets that can produce a permanent backup
(preferably paper)
Encryption is a major upside, too, but people new enough to Bitcoin that
they need such a simple client, can survive without encryption (thye're not
going to be holding a ton of coins) -- as long as they are made aware that
they do not currently have encryption, and the associated risks (and other
options).
I think it's extremely important that users have a clear way to backup
their coins to offline media or paper, in such a way that they don't ever
need to worry about it again. Not only does it give users protection
against hard-drive loss, it means that they may find it again in the far
future when they haven't used Bitcoin in 2 years, and it reminds them that
they still have coins (and they don't have to type in 1000 private keys to
get their coins)
For that reason, I think Multibit is an excellent choice. I haven't spent
much time with it, but I do understand it to satisfy (1) and (2) clearly,
and (3) may be happening in the near future (along with encryption). But I
do wonder if it has enough staffing behind it to be the center of attention
(no offense to jim618, but if this becomes the "de-facto" client for new
users, we should make sure there's a lot of people available to support it
-- what if a major security bug is found? how long would it take the
current team to identify, fix and test that bug?)
-Alan
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike at plan99.net> wrote:
> At the moment if you visit bitcoin.org then you're recommended to
> download the full client. I think we all agree that at some point we
> need to start presenting users with something more like this:
>
>
> To get started, download wallet apps A or B.
>
> If you'd like to contribute your computing resources to the Bitcoin
> network and have a fast computer with an unfiltered internet
> connection, download:
>
> - for desktop machines, Bitcoin-Qt
> - for servers, bitcoind
>
>
>
> Obviously not that exact wording.
>
> I personally feel it's a bit early for this, but it's true that users
> are being turned away by the fact that they're pointed to Bitcoin-Qt
> by default, so having some kind of roadmap or plan for changing that
> would be good.
>
> I think MultiBit is maturing into a client that I'd feel comfortable
> recommending to end users who take the fast-start path, though it
> still has a few serious lacks (encrypted wallets aren't released yet,
> bloom filters will help performance a lot, needs to catch up with some
> newer features). But there doesn't have to be a one true client.
>
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work. MultiBit has some unique features that
> are quite useful like integrating charting and exchange rate feeds.
>
> What does everyone think on this?
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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/20121204/f76a7294/attachment.html>

2023-06-07 12:44:52

- reply

📅 Original date posted:2012-12-03
📝 Original message:These are all valid points. I hadn't really thought much about this point
until you all just brought it up. The reason I so quickly spout off that
phrase, is that I endlessly get requests from Armory users to implement
more anonymity-based features. When I say there are bigger priorities,
they suggest that "anonymity" is a core benefit of Bitcoin and I should be
supporting it. I'm not against anonymity, and I most certainly favor
privacy, but my goal was to produce a versatile client, not one focused on
any one aspect -- there are plenty of people who use it for other reasons
than anonymity.
However, I do like Greg's comment about "attacks" against a
blind-dust-inclusion algorithm, and suggestion to maintain a clustering of
already-linked addresses. That's not terribly difficult to do with the
transaction history in hand, and it could increase how often the logic
triggers. I suppose these hardcore SD players probably have a lot of
one-satoshi outputs that could use vacuuming...
On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair <stephen at bitpay.com> wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> Second thing, it's best to carefully separate "anonymity" from
>> "privacy". Privacy is supposed to be a feature of the system (it says
>> so in Satoshis paper) because people demand it. If I loan a tenner to
>> my friend and he is able to find out what I earned last month, then
>> that trade was neither anonymous nor private. In this case I want
>> privacy but anonymity isn't useful. Mixing up anonymity with privacy
>> is not only a public relations problem, but can lead to confusion from
>> users when they, eg, try and buy Bitcoins from an exchange and are
>> asked to provide ID proofs.
>
>
> I would like to second this point...privacy is essential because the
> market demands it. If Bitcoin doesn't do it well (and I would argue that
> it doesn't today), then eventually a competitor to Bitcoin will do it
> better and that would be the beginning of the end for Bitcoin. Debates
> about whether it was or wasn't a core feature are pointless.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/cc823863/attachment.html>

2023-06-07 12:44:42

- reply

📅 Original date posted:2012-12-03
📝 Original message:On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
> (1) Make client software aggressive about sweeping up dust inputs:
> "Any time a transaction is created that has change keep adding in
> extra inputs— smallest to largest— until an additional one would
> increase the cost of the transaction by 0.0001 BTC or more" — the only
> major complication is doing this without concurrently harming privacy
> which is why it's not done yet in the reference client.
FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions. However, there's enough conditions on it, that
I don't know how often it triggers. Recommendations are welcome for how
to improve it.
Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly. Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this. (reorganized the code
<https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279>
recently, and must have fell through the cracks).
Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior. After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to "opt-out" of that logic if user cares. I think
most users don't actually care...
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/d0a9abab/attachment.html>

2023-06-07 12:21:39

- reply

📅 Original date posted:2012-07-09
📝 Original message:On 07/09/2012 10:36 PM, Stefan Thomas wrote:
>> It looks like that because feature matrices aren't especially helpful
>> for newbies to make a decision, especially when the "features" in
>> question were often things like how they handled the block chain or
>> which protocol standards they support, ie, things only of interest to
>> developers.
> A well-designed feature matrix can quite useful and user-friendly.
>
> http://www.apple.com/ipod/compare-ipod-models/
>
> Prose is better to get a sense of the philosophy and basic idea of a
> client. If it was between having only a feature matrix or only prose,
> I'd probably go for the prose as well.
>
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
>
If we're keeping the clients page, I would really like to see the
feature matrix linked from that page. It shouldn't be on that main
clients page (for the reasons already stated), but Stefan makes a point
that /it is really useful for many users./ Add "Compare features of the
various different clients here: <link>" and users who will benefit will
most definitely click on it. I think that's win-win.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120709/5376969f/attachment.html>

2023-06-07 12:21:16

- reply

📅 Original date posted:2012-07-09
📝 Original message:I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that "clients" page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
link of where to find more information (i.e. the wiki). I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.
We either have to have a "czar" who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call. Or we just move it to another page that is less
strictly controlled and where these things matter less. Trying to gain
consensus among an amalgamation of developers all with competing priorities
and "products" is a terrible way to try to agree on stuff.
-Alan
On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> > JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> JS randomization doesn't imply needing JS to view the page. It implies
> needing JS to see it in random order. You could also combine it with
> the server-side randomization if you care about non-js being non
> random, though I don't think it matters.
>
> As others have pointed out I don't generally think the randomization
> is good in principle, but if its done it should at least achieve its
> goals.
>
> > Only you have a problem with this page. I don't see why Bitcoin-Qt needs
> to be first either when it dominates the front page. It is perfectly fine
> as it is.
>
> I'll let other people speak for themselves, but I did consult others
> before reverting your last batch of changes.
>
> More generally, we have pull requests in order to get some peer review
> of changes. Everyone should use them except for changes which are
> urgent or trivially safe. (Presumably everyone with access knows how
> to tell if their changes are likely to be risky or controversial)
>
> > You are not a developer of any alternative clients, and this is a
> webpage for Bitcoin clients. I have made a change to remove a source of
> disputes, and make the process more fair and equal. Your suggestion to
> remove the clients page is your bias towards thinking that there should be
> only one Bitcoin client that everyone uses (the one which you contribute
> towards).
>
> I'm strongly supportive diversity in the Bitcoin network, and some alt
> client developers can speak to the positive prodding I've given them
> towards becoming more complete software. If I've said anything that
> suggests otherwise I'd love to be pointed to it in order to clarify my
> position.
>
> Unfortunately none of the primary alternatives are yet complete, the
> network would be non-function if it consisted entirely of multibit or
> electrum nodes (and as you've noted armory uses a local reference
> client as its 'server'). The distinction between multiple kinds of
> clients in terms of security and network health are subtle and can be
> difficult to explain even to technical users and so until something
> changes there the reference client needs to be the option we lead
> with. People should us it unless their use-case doesn't match. When it
> does they'll know it and they'll be looking. We don't need to make one
> of those recommendations a primary option.
>
> I like the proposals of moving this stuff to the Wiki as the wiki
> already contains tons of questionable (and sometimes contradictory)
> advice and so there is less expectation that placement there implies
> any vetting.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120709/664e705e/attachment.html>

2023-06-07 12:18:24

- reply

📅 Original date posted:2012-06-19
📝 Original message:On 06/19/2012 02:18 PM, Mark Friedenbach wrote:
> On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
> If we were to use a raw trie structure, then we'd have all the above
> issues solved: a trie has the same configuration no matter how
> elements
> are inserted or deleted, and accesses to elements in the tree are
> constant time -- O(1). There is no such thing as an unbalanced trie.
> But overall space-efficiency is an issue.
>
> A PATRICIA tree/trie would be ideal, in my mind, as it also has a
> completely deterministic structure, and is an order-of-magnitude more
> space-efficient. Insert, delete and query times are still O(1).
> However, it is not a trivial implementation. I have occasionally
> looked
> for implementations, but not found any that were satisfactory.
>
>
> No, a trie of any sort is dependent upon distribution of input data
> for balancing. As Peter Todd points out, a malicious actor could
> construct transaction or address hashes in such a way as to grow some
> segment of the trie in an unbalanced fashion. It's not much of an
> attack, but in principle exploitable under particular timing-sensitive
> circumstances.
>
> Self-balancing search trees (KVL, RB, 2-3-4, whatever) don't suffer
> from this problem.
>
> Mark
I was using "unbalanced" to refer to "query time" (and also
insert/delete time). If your trie nodes branch based on the next byte
of your key hash, then the max depth of your trie is 32. Period. No
one can do anything to ever make you do more than 32 hops to
find/insert/delete your data. And if you're using a raw trie, you'll
always use /exactly/ 32 hops regardless of the distribution of the
underlying data. Hence, the trie structure is deterministic
(history-independent) and cannot become unbalanced in terms of access time.
My first concern was that a malicious actor could linearize parts of the
tree and cause access requests to take much longer than log(N) time.
With the trie, that's not only impossible, you're actually accessing in
O(1) time.
However, you are right that disk space can be affected by a malicious
actor. The more branching he can induce, the more branch nodes that are
created to support branches with only one leaf.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120619/2548286d/attachment.html>

2023-06-07 12:18:18

- reply

📅 Original date posted:2012-06-19
📝 Original message:On 06/19/2012 01:59 PM, Gregory Maxwell wrote:
> On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner<etotheipi at gmail.com> wrote:
>> One app developer updates their
>> RB tree code which updated the RB-tree optimizations/rebalancing, and
>> now a significant portion of the network can't agree on the correct
>> root. Not only would that be disruptive, it would be a disaster to
>> track down.
> This is why good comprehensive tests and a well specified algorithim
> are important. The tree update algorithm would be normative in that
> scheme. Worrying that implementers might get it wrong would be like
> worrying that they'd get SHA256 wrong.
The point is not that they get it *wrong*, it's that the implement it
*differently*. Given a set of 100 TxOuts, there's a seemingly-infinite
number of ways to construct a binary tree. Put them in in a different
order, and you get a different tree. *They're all correct and legal* in
terms of satisfying expectations of insert, delete and query runtime --
but they will produce different root hashes. And the differences in
underlying structure are completely transparent to the calling code.
I'm extremely uncomfortable with the idea the you can have all the nodes
in the tree, but have to replay X years of blockchain history just to
get the same tree configuration as someone else. However, a trie
configuration is history-independent -- given an unspent-TxOut list,
there's only one way to construct that tree. That's an important
property to me.
I can't tell if you're joking about Judy structures: I've never heard of
them. But I'll look into it anyway...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120619/5426be15/attachment.html>

2023-06-07 12:18:11

- reply

📅 Original date posted:2012-06-19
📝 Original message:I hope that someone else here would chime in on the issue raised in the
thread, about using a tree-structure that has multiple valid
configurations for the same set of unspent-TxOuts. If you use any
binary tree, you must replay the entire history of insertions and
deletions in the correct order to get the tree structure and correct
root. Along those lines, using something like a red-black tree, while
theoretically well-known, could be subject to implementation errors.
One implementation of a red-black tree may do the rebalancing
differently, and still work for it's intended purpose in the majority of
applications where it doesn't matter. One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
root. Not only would that be disruptive, it would be a disaster to
track down.
If we were to use a raw trie structure, then we'd have all the above
issues solved: a trie has the same configuration no matter how elements
are inserted or deleted, and accesses to elements in the tree are
constant time -- O(1). There is no such thing as an unbalanced trie.
But overall space-efficiency is an issue.
A PATRICIA tree/trie would be ideal, in my mind, as it also has a
completely deterministic structure, and is an order-of-magnitude more
space-efficient. Insert, delete and query times are still O(1).
However, it is not a trivial implementation. I have occasionally looked
for implementations, but not found any that were satisfactory.
So, I don't have a good all-around solution, within my own stated
constraints. But perhaps I'm being too demanding of this solution.
-Alan
On 06/19/2012 12:46 PM, Andrew Miller wrote:
>> Peter Todd wrote:
>> My solution was to simply state that vertexes that happened to cause the
>> tree to be unbalanced would be discarded, and set the depth of inbalance
>> such that this would be extremely unlikely to happen by accident. I'd
>> rather see someone come up with something better though.
> Here is a simpler solution. (most of this message repeats the content
> of my reply to the forum)
>
> Suppose we were talking about a binary search tree, rather than a
> Merkle tree. It's important to balance a binary search tree, so that
> the worst-case maximum length from the root to a leaf is bounded by
> O(log N). AVL trees were the original algorithm to do this, Red-Black
> trees are also popular, and there are many similar methods. All
> involve storing some form of 'balancing metadata' at each node. In a
> RedBlack tree, this is a single bit (red or black). Every operation on
> these trees, including search, inserting, deleting, and rebalancing,
> requires a worst-case effort of O(log N).
>
> Any (acyclic) recursive data structure can be Merkle-ized, simply by
> adding a hash of the child node alongside each link/pointer. This way,
> you can verify the data for each node very naturally, as you traverse
> the structure.
>
> In fact, as long as a lite-client knows the O(1) root hash, the rest
> of the storage burden can be delegated to an untrusted helper server.
> Suppose a lite-client wants to insert and rebalance its tree. This
> requires accessing at most O(log N) nodes. The client can request only
> the data relevant to these nodes, and it knows the hash for each chunk
> of data in advance of accessing it. After computing the updated root
> hash, the client can even discard the data it processed.
>
> This technique has been well discussed in the academic literature,
> e.g. [1,2], although since I am not aware of any existing
> implementation, I made my own, intended as an explanatory aid:
> https://github.com/amiller/redblackmerkle/blob/master/redblack.py
>
>
> [1] Certificate Revocation and Update
> Naor and Nissim. 1998
> http://static.usenix.org/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf
>
> [2] A General Model for Authenticated Data Structures
> Martel, Nuckolls, Devanbu, Michael Gertz, Kwong, Stubblebine. 2004
> http://truthsayer.cs.ucdavis.edu/algorithmica.pdf
>
> --
> Andrew Miller
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 12:09:55

- reply

📅 Original date posted:2012-05-25
📝 Original message:I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed, especially
if it requires spontaneous super-majority-of-nodes acceptance. I think
it's gotta be based on the block itself and each nodes' own info.
If you could spontaneously get all miners to agree not to build off of
anti-social blocks (however that is defined) , it would have a chance of
making a difference, but individual miners would have an advantage
building off the antisocial block because they only need to produce one to
create the longest chain (and collect reward) while the miners following
the rules need two blocks.
--Sent from my overpriced smartphone
On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
wrote:
> How about a simple proof of work test? This one though does not ask for
> CPU work but asks the miner for a random old transaction. If the miner
> really stores the entire blockchain he will not have any problem answering
> to that getdata request, whereas a botnet would have to ask someone else
> for it, which could be detected if the response time deviates too much from
> what has been previously measured (compare it against getdata for the block
> they advertise). It's not perfect but it allows an estimate of whether it
> is a chainless miner.
>
> Regards,
> Chris
> --
> Christian Decker
>
>
>
> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>
>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>> > Block times are not accurate enough for that.
>>
>> The times in your log are very accurate, assuming your system clock is
>> remotely accurate.
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120525/856b88ab/attachment.html>

2023-06-07 12:07:11

- reply

📅 Original date posted:2012-05-02
📝 Original message:Btw, I sent updated text to Genjix Armory. I hope that gets included or
reviewed.
And I agree about the $4k donations thing. That's complete immaterial for
this page. Though the rest of the description there is reasonable, and
might even be better than what I sent Genjix.
-Alan
On Wed, May 2, 2012 at 9:42 AM, Mike Hearn <mike at plan99.net> wrote:
> Bitcoin-qt is translated into a pretty broad set of languages (now— I
>> cant tell you how many of them are _good_). Listing language just
>> under multibit makes it sound like a distinguishing characteristic.
>>
>
> Fair enough then, let's take that out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/93552a6a/attachment.html>

2023-06-07 12:06:58

- reply

📅 Original date posted:2012-05-02
📝 Original message:Oh, like I did 3 hours ago? Gah! I replied directly to grarpamp by
accident. Sorry if this seems out of place now...
I'm all for sorting the clients by "ease of use". We want the smoothest
first experience greeting users new to Bitcoin. I have grand plans of
defaulting Armory to a standard user mode that is standalone, easy to use,
etc. But until then, Armory will remain an a power-users thing, and I'd
prefer not to have Bitcoin n00bs emailing me for support before they know
what Bitcoin-Qt is, or, more likely, installing Armory alone and then
walking away when nothing works.
As someone else mentioned previously, the advanced stuff will generally be
found by advanced users. I think it should still receive exposure through
these means, but not on the top/first row.
I personally think the page should say something like "New to Bitcoin?
Start experiencing Bitcoin with My Phone <menu of phone options>, or My
Desktop <menu of desktop options>" Put the top 3 on each and either a
button for "More Options", or a short list of other options without
screenshots, and just descriptions with links. Ideally, it would be sorted
by popularity, because that's probably the most important metric that ties
together all features into a single number, but we don't have good stats on
that. For now, we settle this by putting Bitcoin-Qt up front, and sort
everything else by how easy it is for users to get started and perceived
popularity and disagreements can be settled by semi-regular rotation.
For now, I don't think ordering is super important. No one here is
threatening lawsuits for improper placement, and the rotation will be good
to keep the main Bitcoin page looking less stagnant, and slowly exposing
repeat visitors to the variety of options available.
--Alan
On Wed, May 2, 2012 at 3:25 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
>
> On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
>
> Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik at exmulti.com>
> To: grarpamp <grarpamp at gmail.com>
> Cc: bitcoin-development at lists.sourceforge.net
> Sent: Wednesday, May 2, 2012 7:29 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >> Try "Reply to All"
> >
> > That puts the sender in 'to' and list in 'cc',
> > which dupes to the sender and eventually
> > blows out the to and cc lines as everyone
> > chimes in and doesn't trim. 'reply to' solves
> > most of that. assuming the list sw can do it.
>
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120502/7e9cd5a0/attachment.html>

2023-06-07 12:06:48

- reply

📅 Original date posted:2012-05-02
📝 Original message:I think it's perfectly reasonable to debate ordering. I personally don't
think Armory should be up front, because it's not intended for beginners.
How's that for honesty? I don't think anyone is trying to game the system
right now, I think we're trying to come up with a reasonable mechanism for
appealing to new users and get the community more connected. And make
sure everyone understands the system.
On the other hand, perhaps it's better to take the acceptable 80% solution,
and revise it over time...
Amir, I don't have access to the page. I've never been able to view it.
Changing my hosts file doesn't seem to do anything. Can you just forward
me the text? I'll send you an approval email.
On Wed, May 2, 2012 at 3:43 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe at froot.co.uk>
> To: "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik at exmulti.com>
> >To: grarpamp <grarpamp at gmail.com>
> >Cc: bitcoin-development at lists.sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik at exmulti.com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120502/08c0ebe1/attachment.html>

2023-06-07 12:06:37

- reply

📅 Original date posted:2012-05-02
📝 Original message:I'm not sure what "designed for occasional use" means. Many users of
other clients use them exclusively without touching other clients. Armory
is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
I'm sure the other clients are the same.
Instead, I think that line would be replaced by a blurb about the target
audience. "Designed for Advanced Users". "Designed for Quick Setup and
Instant usability".
Btw, Armory now has full installers for both Windows and Linux
(Ubuntu/Debian), with uninstallers and automatic URI registration
On Wed, May 2, 2012 at 3:34 PM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik at exmulti.com>
>> To: grarpamp <grarpamp at gmail.com>
>> Cc: bitcoin-development at lists.sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120502/af738a5b/attachment.html>

2023-06-07 12:04:00

- reply

📅 Original date posted:2012-04-12
📝 Original message:My one big concern about this that users find a way to exploit this
behavior for themselves. If it's too easy for users to create tx they know
will get stuck and expire, it's no different than letting them cancel their
zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so
I send it using a combination of inputs and fees that I know will lead to
it being stuck and expire.
On the other hand, if such conditions are deterministic enough, it could be
detected by the recipient and flagged.
It's not a huge deal, but it's something to consider.
-Alan
On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> Not sure whether this rises to the level of a BIP or not, as it is
> largely an implementation change.
>
> One of my From-Day-One complaints about bitcoin is that transactions
> behavior could be far more deterministic (predictable), from a user
> standpoint. Transactions in the current system can easily remain in
> limbo forever.
>
> One big step in making transactions behave more predictably would be
> to remove transactions from the memory pool, if they have not made it
> into a block for a couple days. i.e.
>
> 1. N = 1 or 2 or whatever the community prefers. Ideally enough time
> for a third-tier miner, mining strange TXs, finds a block.
> 2. H1 = height of block chain, when a TX is received
> 3. H2 = H1 + (144 * N)
> 4. If block chain height reaches H2, and TX has not made it into a
> block, drop TX from memory pool
>
> Although this only impacts a small amount of TX's ultimately, what it
> does do is give us the ability -- once miners have upgraded to this
> rule -- to tell bitcoin users that their transactions "expire" after N
> days.
>
> Backwards compatibility should not be an issue; clients are free to
> retransmit their TX at any time, as usual, thereby "resetting the
> clock" for all peers who have forgotten the TX in question.
>
> Once in place, clients may then implement code that notices a TX has
> expired (read: likely to have been forgotten by the network, assuming
> they themselves have stopped retransmitting it). Then you can start
> working on wallet/coin recovery, perhaps resending with a higher fee
> etc.
>
> The above change is not really "fill-or-kill" but it should be a big
> step, opening the door to deterministic TX behavior.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> 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/20120412/8ae4ec6d/attachment.html>

2023-06-07 12:02:58

- reply

📅 Original date posted:2012-04-03
📝 Original message:Mike,
You make an excellent point. Neither of these proposals impact the
protocol itself. I hadn't considered that. But I think it's a
critically important problem to solve (signature blocks, not so much,
but it could piggy back on the same solution). So the mailing list is
a good place to discuss this, but it maybe it shouldn't be labeled as a
BIP. I'll leave that up to the others (arguably, the URI scheme is not
a protocol change, either, but was still a BIP).
There is all this fanfare around P2SH and how multi-sig is the solution
to all these security problems, but how the hell do you use it? I
believe that BIP 10 (or successor) is *critical//*to the success of
multi-sig, because the greatest barrier to using multi-sig will be the
ability to actually execute them in less than 14 steps. And if every
client implements it differently, there's even less chance it will be
used (assuming the userbase reaches any level of client diversity).
I think we need to supply a solution to this existing problem before
everyone starts solving it on their own and fragmenting the market. No
one has to use the solution we come up with -- but I believe it's a
problem for which most developers will take any solution that is easy to
exchange, size-efficient and promised to be interoperable (if for no
other reason than the Satoshi client uses it).
-Alan
On 04/03/2012 07:37 PM, Mike Koss wrote:
> Alan, I'm coming in late to the conversation - do I understand that
> BIP 010 does not propose any changes to the protocol - but just an
> intermediate data format that other clients might use to collect the
> need key material to sign a multi-signature block?
>
> If so - one might ask what the role of BIP's are if they actually do
> not impact the protocol?
>
> If there is any encapsulated data format that is expected to be
> interpreted by clients - I'd call that a "protocol change"; but I take
> it in this instance that you will transmit these signature block out
> of band from the client ... yet they would have to be parsed and
> converted into a Transaction Script once collected by SOME client?
> Would we expect the standard client do so?
>
> Sorry if this has been discussed before - I'm trying to understand the
> proposal.
>
>
> On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
> Just to clarify, I'm not proposing anything to the protocol
> itself. Simply that some applications might benefit from users
> being to sign messages with existing Bitcoin identities, and what
> can we do to accommodate that (out of band)? It's not a high
> priority, but I think it's potentially useful, and most codebases
> already have everything they need in place to implement it.
>
>
>
> On 04/03/2012 04:04 PM, Peter Vessenes wrote:
>> I don't think it's minimally invasive to layer PGP's web of trust
>> on top of Bitcoin, in fact, the opposite.
>>
>> From a certain angle, bitcoin exists as a sort of answer /
>> alternate solution to the web of trust. Digital cash with an
>> existing web of trust in place was a working concept in the
>> mid-1990s, courtesy of David Chaum, I believe.
>>
>> I totally agree on the kitchen sink concern; I would personally
>> like to see something like a one-year required discussion period
>> on all non-security changes proposed to the blockchain protocol.
>> We know almost nothing about how bitcoin will be used over the
>> next 20 years; I believe it's a mistake to bulk up the protocol
>> too rapidly right now.
>>
>> There's a famous phrase from the founder of Lotus about Lotus'
>> engineering process: "add lightness." The equivalent for protocol
>> design might be "add simplicity." I'd like to see us adding
>> simplicity for now, getting a core set of tests together for
>> alternate implementations like libbitcoin, and thinking hard
>> about the dangers of cruft over a 10+ year period when it comes
>> to a technology which will necessarily include a complete history
>> of every crufty decision embodied in transaction histories.
>>
>> Peter
>>
>>
>> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj at gmail.com
>> <mailto:laanwj at gmail.com>> wrote:
>>
>>
>> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke at dashjr.org
>> <mailto:luke at dashjr.org>> wrote:
>>
>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>> > We should avoid reinventing the wheel, if we can. I
>> think we should
>> > extend existing standards whenever possible.
>>
>> I wonder if it's possible to make sigs compatible with
>> PGP/EC ?
>>
>>
>> Or we could take a step back, further into "don't reinvent
>> the wheel" territory. Why not simply make use of PGP(/EC) to
>> sign and verify messages? It has many advantages, like an
>> already existing web-of-trust and keyserver infrastructure.
>>
>> I still feel like this is sign message stuff is dragging the
>> kitchen sink into Bitcoin. It's fine for logging into a
>> website, what you use it for, but anything that approaches
>> signing email (such as S/MIME implementations and handling
>> different character encodings) is going too far IMO.
>>
>> Wladimir
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> --
>>
>> Peter J. Vessenes
>> CEO, CoinLab
>> M: 206.595.9839 <tel:206.595.9839>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>>
>>
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> 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
>
>
>
>
> --
> Mike Koss
> CTO, CoinLab
> (425) 246-7701 (m)
>
> A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you
> need to know about Bitcoins.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120403/c9b724a0/attachment.html>

2023-06-07 12:02:55

- reply

📅 Original date posted:2012-04-03
📝 Original message:On 04/03/2012 02:46 PM, Gavin Andresen wrote:
> RE: signature blocks and BIP 10:
>
> We should avoid reinventing the wheel, if we can. I think we should
> extend existing standards whenever possible.
>
> So: could we encode signature blocks or BIP-10 transactions using
> S/MIME ? Or is there a more appropriate "sign a message" standard we
> could/should use?
>
> You're glossing over little details like what character encoding is
> used for the message, but I'd rather leverage all the work already
> done by the IETF to nail down all those little details rather then
> re-discover them and come up with our own solutions.
>
I'm glossing over details because I actually have no experience dealing
with character encodings, or the implementation specifics of existing
solutions (PGP or S/MIME). That's why I'm emailing this list: I want
to figure this stuff out, and at the same time try to converge on
something that is efficient and can be interoperable between Armory and
the Satoshi client (wallets, signature collection, sig blocks).
I don't go into these things solely to reinvent stuff. My primary
motivation for both ideas I have pitched so far (BIP 0010 and the sig
blocks) is the versatility. I like the encoding-independent, visual
compactness of PGP ASCII-armored text blocks, but I don't like their
opaqueness. PGP vs my signature blocks basically look the same to a
casual user, but even a moderately-knowledgeable user can appreciate the
human-readable components of it. You can visually identify if
signatures are missing from sig-collection packet, or see that you
signed with the wrong address without having to load an external program.
But that isn't a critical requirement, it's just my personal
preference. I'm fine with existing systems if it sidesteps a lot of
problems and there's easy interface to it. But, I don't want to have
another BSDDB-wallet situation where we end up with 10x more capability
than we need, and pay for it with 10x the complexity (at least in this
case, using PGP is an existing crypto/security-sensitive technology). I
have made "simplicity" one of my goals in Armory.
Alternatively, we could change the discussion to a requirements
discussion, to first figure out what we need in order to address
multi-signature collection, etc. Then evaluate competing ideas based on
their qualities relative to the requirements.

2023-06-07 12:02:48

- reply

📅 Original date posted:2012-04-03
📝 Original message:Just to clarify, I'm not proposing anything to the protocol itself.
Simply that some applications might benefit from users being to sign
messages with existing Bitcoin identities, and what can we do to
accommodate that (out of band)? It's not a high priority, but I think
it's potentially useful, and most codebases already have everything they
need in place to implement it.
On 04/03/2012 04:04 PM, Peter Vessenes wrote:
> I don't think it's minimally invasive to layer PGP's web of trust on
> top of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of
> trust in place was a working concept in the mid-1990s, courtesy of
> David Chaum, I believe.
>
> I totally agree on the kitchen sink concern; I would personally like
> to see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know
> almost nothing about how bitcoin will be used over the next 20 years;
> I believe it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol
> design might be "add simplicity." I'd like to see us adding simplicity
> for now, getting a core set of tests together for alternate
> implementations like libbitcoin, and thinking hard about the dangers
> of cruft over a 10+ year period when it comes to a technology which
> will necessarily include a complete history of every crufty decision
> embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj at gmail.com
> <mailto:laanwj at gmail.com>> wrote:
>
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke at dashjr.org
> <mailto:luke at dashjr.org>> wrote:
>
> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> > We should avoid reinventing the wheel, if we can. I think we
> should
> > extend existing standards whenever possible.
>
> I wonder if it's possible to make sigs compatible with PGP/EC ?
>
>
> Or we could take a step back, further into "don't reinvent the
> wheel" territory. Why not simply make use of PGP(/EC) to sign and
> verify messages? It has many advantages, like an already existing
> web-of-trust and keyserver infrastructure.
>
> I still feel like this is sign message stuff is dragging the
> kitchen sink into Bitcoin. It's fine for logging into a website,
> what you use it for, but anything that approaches signing email
> (such as S/MIME implementations and handling different character
> encodings) is going too far IMO.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> 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
>
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> 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/20120403/c948c48e/attachment.html>

2023-06-07 12:02:29

- reply

📅 Original date posted:2012-04-02
📝 Original message:I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long, but
I felt both should be in the same email...
_*(1) Signature Blocks* -- A more-robust, versatile, message-signing
exchange_
Satoshi client 0.6.0 introduced message signing, but I've been fairly
unimpressed with the implementation. Strictly speaking, it works, but
it's really not intended for "regular users." There is no indication of
what message was signed or what address signed it. Key recovery works
for the computers processing it, but the user has no idea what this
chunk of random data is. They don't even know if the message they
thought they signed is what's in the signature (along the lines of the
copy&paste virus, the message could be switched out without the user
noticing).
I have implemented Signature Blocks
<https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163> in
Armory (as of v0.55), which is a fully-functional expansion on the
idea. Along the lines of BIP 10, a signature block is a human-readable
chunk of data that immediately identifies the address and the message
that are being signed. It is easily copy&pasted via email or text
files, and is fairly compact for visual identification. Click the link
above to see an example signature block and an Armory screenshot of the
UI (which needs improvement, but still usable). The verification
process will include:
-- Check that the public key (included or recovered) matches the address
field.
-- Verify that the signature matches the included message for this
public key
-- The message is properly formatted with a standardized character set
and escape/replacement scheme for things like newlines or double-quotes.
gmaxwell already pointed out that key recovery makes the "Public Key"
field pointless. Okay fine -- I just don't have key recovery
implemented yet in Armory, and when I do I can ditch that field (or
simply make it optional). The point is to create a versatile,
human-readable standardized form, much like the BIP 0010
signature-collection scheme <https://en.bitcoin.it/wiki/BIP_0010>.
_*(2) Sign-Message URI scheme***-- Request signed messages from users
using URIs_
I had the idea that for certain services, the first funding address
could be used to identify the owner of an account, and all account
maintenance (such as cashouts) be done through signed messages with this
address. For instance, the user would need both a login password *and*
a signed message in order to make a withdrawal or purchase:
("Please withdraw 12.3 BTC from acct 1828349132 to address
1Hfr3jk2093f")_signed_by_A
This gives the service the ability to use two separate factors to
authenticate the request (username&password *and* access to unencrypted
wallet). This /could/ work with manual signature blocks alone... but
it's too many steps for regular users. However, I think it's workable
if we expand bitcoin URIs to include "Signature Requests".
The URI scheme would add a few parameters to the scheme, and would have
to have further replacement rules to make sure that messages are handled
properly. The general CONOPs would be (*Con*cept of *Op*eration*s*):
-- User navigates to "Withdraw funds" on webpage
-- Webpage has you fill in the details: from-account, to-address,
withdrawal amount
-- Webpage produces a clickable URI link that loads all the
information into your client, including addr-reqd-for-sig
-- Client asks for confirmation and passphrase (if necessary) then
produces a signature (and sig block if necessary)
-- URI may include reply-to field that tells it where to send the
siganture when it's ready
So the extra tags that would be needed would probably be:
"*requestSig*=True":
Flag to identify that this is a signing request URI
"*sigNeeded*=1Qjf3392k31h"
The address that needs to sign the message
"*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"
Some encoding of the message that can be parsed the
same way on all systems
"*replyurl*=http://requestor.com/sig_replies.asp?"
(Optional) After signing, application will submit the
signature to the replyurl
The reply url could be simply an http URL which will use bitcoin URI
syntax, with the fields above copied. Therefore, to complete the above
request, the application handling the request will simply send an HTTP
request to:
http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h&*message*=...&*signature*=1fb1893ac193...&*replySig*=True
Any thoughts? (I have no doubts that there are :) )
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120402/8c315b70/attachment.html>

2023-06-07 04:56:14

- reply

📅 Original date posted:2012-01-16
📝 Original message:You guys are representing both extremes of the issue. In response to
Jeff and Luke-Jr, I don't see how this is /just any other poltical
issue/. It strikes at the heart of everything Bitcoin is about.
Barring Bitcoin-specific legislation, I don't see how any legislation
could be more relevant to Bitcoin and the community around it.
On the other hand, Bitcoin is still a non-entity, and shouldn't get in
the business of making statements. A central voice for Bitcoin gives
the impression that it is actually centralized, and one that has
opinions. Plus I wouldn't be surprised if some, heavily-invested
Bitcoin users were of the opinion that SOPA/PIPA/whatever could be a
huge profit for themselves: once SOPA kicks in and businesses around
the world start getting cut off for legit or illegitimate purposes, a
lot of them could potentially switch to Bitcoin to keep their business
going. That could be a huge boon for Bitcoin. You may not agree it's
worth the tradeoff, but people are selfish and may not actually
understand or even care about SOPA legislation itself.
I think it's /not inappropriate/ for something to be mentioned on the
website about Bitcoin's philosophy being threatened by SOPA, but I agree
Bitcoin should avoid making any bold political stands. Users could be
reminded that SOPA affects yet another thing they care about, but it
might be better to avoid it altogether. If any response is made, it
should be a very light one.
-Alan
On 01/16/2012 07:30 PM, Amir Taaki wrote:
> Bunk argument. This is an issue that affects bitcoin directly.
>
> Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.
>
> http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action
>
> The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.
>
> It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik<jgarzik at exmulti.com>
> To: Amir Taaki<zgenjix at yahoo.com>
> Cc: "bitcoin-development at lists.sourceforge.net"<bitcoin-development at lists.sourceforge.net>
> Sent: Sunday, January 15, 2012 10:37 PM
> Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
>
> On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki<zgenjix at yahoo.com> wrote:
>> How is this not the most important world issue right now?
>>
>> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>>
>> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
>
> There are always issues that raise ire and moral outrage. I would
> rather that bitcoin.org stay apolitical -- our users will appreciate
> this in the long run.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120116/5083fc3c/attachment.html>

2023-06-07 04:51:26

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: Headers-only clients can still maintain the same level of security as full nodes by basing verification decisions on hash comparisons. Blockchain pruning is critical for scalability and decentralization.
📝 Original message:The whole point of having headers built at a constant size and
generation rate is to minimize the amount of data needed to "understand"
of the blockchain while simultaneously maximizing integrity/security in
the presence of untrusted nodes. Barring the 50%-attack, you only need
a couple honest nodes out of 50 to stay safe (as long as you're waiting
for your 6 confirmations). In fact, I would argue that a full node
(Satoshi client), has the same level of security as a headers-only
client... because they both base *all* their verification decisions on
computations that end with comparing hashes to the longest-chain headers.
In the case that an attacker figures out how to isolate your node
entirely and start feeing you poisoned blocks, then you are vulnerable
with any kind of node, full or lightweight. I don't see where the
reduced security is.
The only issue I see is that a truly light-weight, headers-only node
will be having to download an entire block to get one transaction it
needs. This would be significantly alleviated if nodes can start
requesting merkle-trees directly, even without merkle-branch-pruning.
If a node can ask for a tx and the tx-hash-list of the block that
incorporated that tx, he can easily verify his tx against his
no-need-to-trust-anyone headers, and doesn't have to download MBs for
every one.
As for blockchain pruning... I think it's absolutely critical to find a
way to do this, /for all nodes/. I am swayed by Dan Kaminsky's
scalability warnings, and my instinct tells me that leaving full
verification to a select few deep-pockets nodes in the future opens up
all sorts of centralization/power-corporation issues that is contrary to
the Bitcoin concept. It is in everyone's best interest to make it as
easy as possible for /anyone/ to act as a full node (if possible). As
such, I believe that the current system of minimizing TxOut size is the
right one. TxIns take up 0 bytes space in the long-run when taking into
account any blockchain pruning/snapshot idea (except for nLocktime/seq
transactions where the TxIn might have to be saved).
-Alan
On 12/18/2011 12:09 PM, theymos wrote:
> On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote:
>> I don't like the idea of a header only client, unless this is just an
>> interim action until the full block chain is downloaded in the
>> background. Development of these types of clients is probably
>> inevitable, but I believe that this breaks the most fundamental
>> aspects of Bitcoin's security model. If a client has only headers, it
>> cannot do full verification, and it is trusting the data from random
>> anonymous peers.
> A headers-only client is much better than trusting anyone, since an
> attacker needs>50% of the network's computational power to trick
> such clients.
>
> For everyone to keep being a full node, hardware costs would need to
> constantly go down enough for all nodes to be able to handle enough
> transactions to meet demand. If hardware doesn't become cheap enough
> quickly enough, either some people would be unable to handle being full
> nodes, or the max block size wouldn't rise enough to meet demand and
> transaction fees would become noncompetitive.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> 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/20111218/e262a49a/attachment.html>

2023-06-07 04:38:45

- reply

📅 Original date posted:2011-11-10
🗒️ Summary of this message: BIP 0010 aims to create a standard solution for multi-signature transactions to prevent fragmentation of protocols and encourage adoption by developers.
📝 Original message:The purpose of creating BIP 0010 now, is to encourage a standard that
developers /want/ to adopt, from the outset. Every developer who is
planning to touch multi-signature transactions, is going to have to
solve the problem of multi-sig tx exchanges, eventually. By offering an
excellent solution before they've started asking the question, there's a
good chance people will use it. Hear me out...
Protocols get fragmented when there's multiple competing ways to do
something, each having some advantages the others don't have. This
leads to developers with differing priorities picking different ones, or
creating their own. However, I believe that the problem BIP 0010 seeks
to solve is a fairly straightforward problem. There's not a lot of
variety in the solutions that could compete against it. People just
need a way to pass this data around, and they want it to be as
convenient to use, and as easy to implement as possible. In that sense,
I think BIP 0010 (or some future variant) is fairly optimal as a
building block for higher-level protocols.
If anyone has ideas for why someone would want to create a competing
idea to BIP 0010 (besides not being aware of it when they start), I'd
like to discuss it. I'm fairly confident that any such ideas could just
be added to BIP 0010 and thus reset the question of why anyone would
need a competing idea.
On 11/09/2011 03:03 PM, Michael Grønager wrote:
> My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the
>
> /M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111109/cad71620/attachment.html>

2023-06-07 04:38:19

- reply

📅 Original date posted:2011-11-09
🗒️ Summary of this message: Proposal for a super-lightweight client that only signs transactions without needing the blockchain, but with a minor problem that needs to be addressed. Third-parties could host a service for this kind of exchange.
📝 Original message:Actually, I'm not sure if your solution works, because it relies on
broadcasting a tx to the network that isn't valid. I believe that the
first tx in your proposal will be rejected and thus you'll need to exchange
the tx's offline.
However, third-parties could pretty easily and conveniently host a service
for this kind of exchange.
--Sent from my overpriced smartphone
On Nov 9, 2011 9:43 AM, "Alan Reiner" <etotheipi at gmail.com> wrote:
> That's what my proposal was for, in BIP 0010:
>
> https://github.com/genjix/**bips/blob/master/bip-0010.md<https://github.com/genjix/bips/blob/master/bip-0010.md>
>
> However, I just found a minor problem with it that should be addressed if
> we want to enable super-lightweight clients that only sign tx's without
> needing the blockchain. Simply that the TxIns don't contain the value of
> the TxOuts they are spending, which means the dumb tx-signers with no
> blockchain can't tell how much input there is. They can only see the
> output values and recipients, which means they can't figure out the tx fee,
> or how much money is in each of the TxIns they are signing.
>
> And most users/clients will have access to the blockchain, so it's not a
> dealbreaker. But it's something to consider. Otherwise, I think this is a
> big step towards bringing this complicatedprotocol a little closer to
> Earth...
>
>
>
>
>
>
> On 11/09/2011 05:22 AM, Michael Grønager wrote:
>
>> Hi All,
>>
>> Along with the multisig/op_eval BIPs (11/12) I am considering how the
>> actual client functionality could be.
>>
>> Some of you might already have the solution for this - if not I would
>> like to propose the following...
>>
>> Lets consider the 2 of 3 multisig - and lets say I now have some coins
>> hence only redeemable using 2 key signatures. So when I want to spend them
>> I would do:
>>
>> 1. from client1 I issue a transaction containing one of the signatures,
>> with a locktime e.g. 10 minutes from now and a sequence of 0. This
>> transaction is now posted to the p2p network.
>>
>> 2. client2 discovers the transaction and that it will affect its wallet.
>> It hence modifies the transaction to includes also the second signature,
>> changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and
>> retransmits the transaction.
>>
>> 3. The transaction is now valid and final and will be approved by the
>> miners.
>>
>> However, for this setup to be possible, we need to reenable the
>> replacement of transaction in the client....
>>
>> Anyone working on this now ?
>>
>> Alternatively, the transactions would need to be sent between clients
>> using another protocol...
>>
>> Cheers,
>>
>> Michael
>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-**sfdev2dev1 <http://p.sf.net/sfu/rsa-sfdev2dev1>
>> ______________________________**_________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.**sourceforge.net<Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/**lists/listinfo/bitcoin-**development<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111109/5d8a635d/attachment.html>

2023-06-07 04:38:16

- reply

📅 Original date posted:2011-11-09
🗒️ Summary of this message: A proposal was made in BIP 0010 to enable super-lightweight clients that only sign transactions without needing the blockchain, but a minor problem was found where the TxIns don't contain the value of the TxOuts they are spending, making it difficult for dumb tx-signers to determine the input amount. This is not a dealbreaker as most users/clients have access to the blockchain.
📝 Original message:That's what my proposal was for, in BIP 0010:
https://github.com/genjix/bips/blob/master/bip-0010.md
However, I just found a minor problem with it that should be addressed
if we want to enable super-lightweight clients that only sign tx's
without needing the blockchain. Simply that the TxIns don't contain the
value of the TxOuts they are spending, which means the dumb tx-signers
with no blockchain can't tell how much input there is. They can only
see the output values and recipients, which means they can't figure out
the tx fee, or how much money is in each of the TxIns they are signing.
And most users/clients will have access to the blockchain, so it's not a
dealbreaker. But it's something to consider. Otherwise, I think this
is a big step towards bringing this complicatedprotocol a little closer
to Earth...
On 11/09/2011 05:22 AM, Michael Grønager wrote:
> Hi All,
>
> Along with the multisig/op_eval BIPs (11/12) I am considering how the actual client functionality could be.
>
> Some of you might already have the solution for this - if not I would like to propose the following...
>
> Lets consider the 2 of 3 multisig - and lets say I now have some coins hence only redeemable using 2 key signatures. So when I want to spend them I would do:
>
> 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network.
>
> 2. client2 discovers the transaction and that it will affect its wallet. It hence modifies the transaction to includes also the second signature, changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and retransmits the transaction.
>
> 3. The transaction is now valid and final and will be approved by the miners.
>
> However, for this setup to be possible, we need to reenable the replacement of transaction in the client....
>
> Anyone working on this now ?
>
> Alternatively, the transactions would need to be sent between clients using another protocol...
>
> Cheers,
>
> Michael
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 04:35:32

- reply

📅 Original date posted:2011-10-25
🗒️ Summary of this message: The proposed OP_EVAL tool for multi-signature transactions is optional, and regular OP_CHECKMULTISIG can still be used. It is important to keep the subscripts/mappings in the wallet forever, and there should be an easy way to add such a script/mapping to the wallet.
📝 Original message:On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111025/e630403f/attachment.html>