Zell Faze [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-12-12 to 2012-04-30
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:05:34

- reply

📅 Original date posted:2012-04-30
📝 Original message:Although quite true, I actually agree though that there should be some sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or ever), but it may be at some point. This change will help Bitcoin scale.
------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate
--- On Mon, 4/30/12, Amir Taaki <zgenjix at yahoo.com> wrote:
> From: Amir Taaki <zgenjix at yahoo.com>
> Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
> To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
> Date: Monday, April 30, 2012, 3:11 PM
> This is optimisation where it isn't
> needed. Bandwidth is not the bottleneck of the Bitcoin
> system. It is the immense time needed to validate the
> blockchain.
>
> And clients should never send blocks first. They always send
> an inv packet, then you request the block. It is a
> disruptive change and brings little.
>
> We don't need to optimise every aspect of Bitcoin :) Just
> focus on the big bits that matter, while keeping everything
> working with minimal changes.
>
> For instance say we did this and to maintain backwards
> compatible, we introduced a new message called "hash+block".
> Now there are 2 code branches that must be maintained -
> urgh.
>
>
> ________________________________
> From: Wladimir <laanwj at gmail.com>
> To: Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com>
>
> Cc: bitcoin-development at lists.sourceforge.net
>
> Sent: Monday, April 30, 2012 7:26 PM
> Subject: Re: [Bitcoin-development] BIP to improve the
> availability of blocks
>
>
> On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge)
> <rebroad+sourceforge.net at gmail.com>
> wrote:
>
>
> >My proposal is that in addition to the size (which is
> advertised in
> >the header), the hash is also advertised in the header
> (of a block).
> >This would help nodes to determine whether they wanted
> to reject the
> >download. (e.g. if it already had a block matching that
> hash). This of
> >course wouldn't prevent a rogue node from sending an
> incorrect hash,
> >but this would aid in saving bandwidth amongst behaving
> nodes.
> >
>
> I suppose it would make sense for clients to be able to
> reject blocks that they already have, if that's not
> currently possible.
>
>
> The other part of the proposal is to allow nodes to request
> upload and
> >download blocks that have already been partially
> downloaded.
> >
> >This could be done by modifying the existing methods of
> upload,
> >download, or by adding a new method, perhaps even using
> HTTP/HTTPS or
> >something similar. This would also help nodes to obtain
> the blockchain
> >who have restrictive ISPs, especially if they are being
> served on port
> >80 or 443. This could perhaps also allow web caches to
> keep caches of
> >the blockchain, thereby making it also more available
> also.
> >
>
> You don't need a BIP if you want to somehow fetch the
> (initial) block chain
> outside the bitcoin protocol. You could download it from
> some http
> server or even pass it along on an USB stick. Then with a
> simple client change you can import it: https://github.com/bitcoin/bitcoin/pull/883 .
>
>
> Currently, without this functionality, nodes with
> restrictive (or
> >slow) internet have some options, such as going via a
> tor proxy, but
> >due to the latency, the problem with multiple receptions
> of the same
> >block still occur.
> >
>
> If you're behind such a slow internet connection, and
> concerned about
> every bit of bandwidth, it is better to run a lightweight
> node. For example, Electrum.
>
> Even if you could reduce the wasted bandwidth a bit by
> puzzling
> around with partial blocks, the download will still be
> substantial (and that's going to get worse before it gets
> better).
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 02:53:21

- reply

📅 Original date posted:2011-12-31
🗒️ Summary of this message: A proposal to restrict the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. Wikipedia founder urges donations.
📝 Original message:I agree with Joel. I think someone brought this up earlier as well. Most OP_EVAL transactions won't be complex enough to require more than a few loops.
--Zell
------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate
--- On Sat, 12/31/11, Joel Joonatan Kaartinen <joel.kaartinen at gmail.com> wrote:
> From: Joel Joonatan Kaartinen <joel.kaartinen at gmail.com>
> Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
> To: roconnor at theorem.ca
> Cc: bitcoin-development at lists.sourceforge.net
> Date: Saturday, December 31, 2011, 4:54 AM
> Wouldn't it work to restrict the
> number of executions of OP_EVAL allowed
> per transaction? That way it wouldn't allow for unlimited
> looping. If
> there's too many OP_EVAL executions during the transaction
> evaluation,
> just consider the transaction illegal. 3 would be enough
> for the
> purposes people have been planning for here I think.
>
> - Joel
>
> On Thu, 2011-12-29 at 11:42 -0500, roconnor at theorem.ca
> wrote:
> > On Thu, 29 Dec 2011, theymos wrote:
> >
> > > On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca
> wrote:
> > >> The number of operations executed is still
> bounded by the number of
> > >> operations occurring in the script.
> With the OP_EVAL proposal the
> > >> script language becomes essentially Turing
> complete, with only an
> > >> artificial limit on recursion depth
> preventing arbitrary computation
> > >> and there is no way to know what code will
> run without executing it.
> > >
> > > Even if OP_EVAL allowed infinite depth, you'd
> still need to explicitly
> > > specify all operations performed, since there is
> no way of looping.
> >
> > That's not true. Gavin himself showed how to use
> OP_EVAL to loop:
> > OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.
> >
> > Basically OP_DUP lets you duplicate the code on the
> stack and that is the
> > key to looping. I'm pretty sure from here we get
> get Turing completeness.
> > Using the stack operations I expect you can implement
> the SK-calculus
> > given an OP_EVAL that allows arbitrary depth.
> >
> > OP_EVAL adds dangerously expressive power to the
> scripting language.
> >
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't
> need a complex
> infrastructure or vast IT resources to deliver seamless,
> secure access to
> virtual desktops. With this all-in-one solution, easily
> deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI
> infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:50:55

- reply

📅 Original date posted:2011-12-25
🗒️ Summary of this message: A trust-based system for nodes in a blockchain network is proposed, where nodes are assigned an initial trust level and transactions are forwarded based on this level. The trust level can be adjusted based on the validity of transactions, and the system can be customized by users. The system aims to prevent untrustworthy nodes from cheating and DDoSing the network. However, there is a potential issue with new nodes being able to send invalid transactions through trusted nodes.
📝 Original message:I may be missing something, but perhaps the simplistic method is the best.
Start all nodes off with a certain level of trust. Lets choose an arbitrary number 5.
If a node's trust level is high enough (lets say 10) forward transactions it sends you without checking them.
If a node's trust level is low enough (lets say 0) discard any transactions they send you (i.e. don't forward them on).
For nodes with a trust level between 1 and 9, forward without checking between 1 and 9 out of every 10 transactions. Check the others, if they are valid, increase the trust level by 1, if they are invalid decrease the trust level by 3.
All of the numbers mentioned here (1-10, 1, 10, 1, 5, and 3) are arbitrary numbers that should be determined by the client or user-preferences instead of the protocol. This would allow for clients to have varying amounts of initial trust/paranoia about their peers.
By decreasing the amount of trust faster than we increase it, we make it harder for untrustworthy clients to cheat us. By having a cut off point, we make it so that untrustworthy clients can not DDoS us. By randomly verifying some transactions in the beginning, we make it harder for a new client from DDoSing us, and we prevent our own trust level from being hurt too much for forwarding on invalid transactions.
The only problem I can personally see with this system is that if Node A trusts Node B with a 10 and Node C connects to Node A, then Node C can send transactions that are invalid to Node C via Node A without Node C being any the wiser. This would be stopped fairly quickly as Node B would catch on and stop forwarding transactions, but it would be a problem for new Nodes.
This could be fixed (somewhat) by having a message that says not to trust a particular node.
--Zell Faze
--- On Thu, 12/22/11, Andy Parkins <andyparkins at gmail.com> wrote:
> From: Andy Parkins <andyparkins at gmail.com>
> Subject: Re: [Bitcoin-development] Protocol extensions
> To: "Joel Joonatan Kaartinen" <joel.kaartinen at gmail.com>
> Cc: bitcoin-development at lists.sourceforge.net
> Date: Thursday, December 22, 2011, 9:46 AM
> On 2011 December 22 Thursday, Joel
> Joonatan Kaartinen wrote:
> > On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins
> wrote:
> > > Why should they have to? Joining the
> network as a node is very low cost
> > > to the other nodes. You can't force any
> node not to be lazy, since
> > > their option is to disconnect themselves.
> As to maliciousness, that is
> > > defended against because when a node negative
> announces a transaction,
> > > that transaction is going to be checked (note
> that there is still no
> > > implicit trust) -- if a node is incorrectly
> negative-announcing then it
> > > can justifiably be kicked.
> >
> > a node that is not doing any checking themselves can
> not reliably
> > forward failed verifications without getting the blame
> for doing faulty
> > work. Those nodes would then have the incentive not to
> relay the failed
> > verifications. This ends up making it important to
> know which nodes will
> > be checking transactions or not so you don't isolate
> yourself from other
> > nodes that are also checking transactions.
>
> Yes; I appreciate that. It's the very point I'm
> making. A node can choose
> what work to do, and should have a way of forwarding the
> results of that work
> to other nodes. Transaction verifification is the
> main one.
>
> Once a negative-announce message exists, it wouldn't be
> hard to have the other
> two you need as well: positive-announce and
> neutral-announce. At present we
> have only neutral-announce. However, as the need for
> super nodes and
> distributed verification gets bigger, having the forwarder
> able to offer an
> opinion on the quality of a transaction seems ideal to
> me. Dishonesty will
> get you isolated pretty quickly if you use
> positive-announce and negative-
> announce to lie.
>
> The problem with this is that it requires a web of trust as
> well as a web of
> connections. The only way to gain an advantage from
> this classified
> forwarding is if you have some way of assigning enough
> trust so that you can
> forward a classified transaction _without_ checking it
> yourself. That doesn't
> sound like an easy problem though.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com
>
> -----Inline Attachment Follows-----
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app
> development. Create
> new or port existing apps to sell to consumers worldwide.
> Explore the
> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:47:03

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Using HTTP servers to respond with addresses is easier than DNS records. It's recommended to use different addresses for each payment. Protect Wikipedia by donating.
📝 Original message:It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record. It is considered a good practice to use a different address for every payment.
------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate
--- On Wed, 12/14/11, Kyle Henderson <k at old.school.nz> wrote:
From: Kyle Henderson <k at old.school.nz>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
To: "Zell Faze" <zellfaze at yahoo.com>
Cc: "Luke-Jr" <luke at dashjr.org>, "Rick Wesson" <rick at support-intelligence.com>, bitcoin-development at lists.sourceforge.net
Date: Wednesday, December 14, 2011, 11:56 PM
Just so we're clear, what is the need for HTTP at all?
A query for a string and an answer can all be handled via DNS.
On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze at yahoo.com> wrote:
Could we combine this proposal and the HTTPS proposal?
The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111214/5a89fb7b/attachment.html>

2023-06-07 02:46:56

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Combining DNSSEC TXT record and HTTPS proposal could provide the dynamism of HTTPS without a rigid URL scheme for querying the server.
📝 Original message:Could we combine this proposal and the HTTPS proposal?
The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC.
--- On Wed, 12/14/11, Rick Wesson <rick at support-intelligence.com> wrote:
> From: Rick Wesson <rick at support-intelligence.com>
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Luke-Jr" <luke at dashjr.org>
> Cc: bitcoin-development at lists.sourceforge.net
> Date: Wednesday, December 14, 2011, 8:22 PM
> understand that not *everyone* wants
> or will adhere to that best
> practice and in my NSHO it isn't.
>
> -rick
>
> 2011/12/14 Luke-Jr <luke at dashjr.org>:
> > On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson
> wrote:
> >> I also am largely in favor of using secured zones
> to publish TXT
> >> records to digital currencies. I've been thinking
> mainly about TXT
> >> using the following format for bitcoin.
> >>
> >> _btc.<lhs>.<rhs>
> >
> > Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in
> general / protocol)...
> > The hard part of using DNS will be sticking to the
> standard good practice of
> > using a new address for every transaction.
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs.
>
> But none more important than the need to reduce IT
> complexity
> while improving strategic productivity. Learn More!
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:45:30

- reply

📅 Original date posted:2011-12-12
🗒️ Summary of this message: Decentralized solutions are needed to implement BIP 15 and maintain Bitcoin's strength. HTTPS is a good client feature, but not for the protocol.
📝 Original message:I agree with Luke-Jr. We need to try to find a decentralized solution if we are going to implement BIP 15. Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength.
I feel like the HTTPS idea would be a great idea for a client feature, but not really something that should be added to the protocol.
--- On Mon, 12/12/11, Luke-Jr <luke at dashjr.org> wrote:
> From: Luke-Jr <luke at dashjr.org>
> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> To: bitcoin-development at lists.sourceforge.net, "Amir Taaki" <zgenjix at yahoo.com>
> Date: Monday, December 12, 2011, 5:32 PM
> FirstBits looks nice at glance, but
> is bound to create a gold-rush to grab
> every nice-looking FirstBits address.
>
> HTTPS is only as secure as the (centralized) CAs, thus not
> really any better
> than TXT records.
>
> I don't think an address of some form is avoidable.